BetaArchive Logo
Navigation Home Database Screenshots Gallery Image Uploader Server Info FTP Servers Wiki Forum RSS Feed Rules Please Donate
UP: 17d, 1h, 15m | CPU: 49% | MEM: 5430MB of 11705MB used
{The community for beta collectors}

Post new topic Reply to topic  [ 121 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sat Mar 09, 2019 10:13 pm 
Reply with quote
FTP Access
User avatar
Offline

Joined
Wed Sep 13, 2017 1:26 am

Posts
356

Location
Tlajomulco de Zuñiga, Jalisco, Mexico.

Favourite OS
Windows Longhorn 6.0.4093
Maybe the FTP path could be a link, like "ftps://releases.betaarchive.com:50000/(Abandonware) Operating Systems/Apple Macintosh/Apple Mac OS 9.0 [Spanish]/"

Not sure about how this could work, but I think it would be neat. It's just a suggestion

_________________
Image
Registrations are now open. Join us today!


Top  Profile  YIM
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sat Mar 09, 2019 10:53 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Fri Aug 18, 2006 11:47 am

Posts
12564

Location
Merseyside, United Kingdom

Favourite OS
Microsoft Windows 7 Ultimate x64
That would serve no purpose since you can't login using your browser.

_________________
Image

BetaArchive Discord: https://discord.gg/epK3r6A


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Mon May 20, 2019 1:24 am 
Reply with quote
Donator
User avatar
Offline

Joined
Sun Jun 05, 2016 9:00 pm

Posts
189

Location
Kurzeme, Latvia

Favourite OS
Windows 7 SP1
A few media names show up blank in the Media Content section.
Here's some that I've found with a release link just as an example:

media_pkg

media_dmg

media_appx

_________________
ATTENTION:
You are now reading my signature

Thank you for your attention!


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Mon May 20, 2019 5:27 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
Added them to the code so they will be corrected in the code later.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Fri Jun 21, 2019 1:08 am 
Reply with quote
FTP Access
Offline

Joined
Sun Apr 08, 2018 1:07 am

Posts
182

Location
Buffalo, New York

Favourite OS
All Windows versions
I have yet another cool suggestion for the BetaArchive database. I think it'd be a nice idea to, I wanna say, enhance the user contributions listings a bit. What I mean by that is, each user page would have a button taking you to a page containing a list of that uploader's contributions and their status. In this case, the list would have all of their contributions, approved or rejected. That section would contain the list of that user's contributions, the date it was uploaded, and then the status, which would say "uploaded", "rejected", or "pending". The ones that say "pending" would have that status until it has been approved or rejected, and would have their status automatically changed to either one of those two. Only the releases that have been approved would have a link to their release page.

Here's a graphic example picture I made to show what I mean a little better,
Image
[click to enlarge]

Would that suggestion be doable?

_________________
[TUT] Install Windows Whistler without setting BIOS date

Image


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Fri Jun 21, 2019 7:44 am 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
It's a neat idea, but it won't happen. Way too much administrative work for me to update all that info for each release. I would spend more time filling out forms to add all this data than actually processing the releases. We can easily tie each release to its contributor through the database, but adding all this extra info would be an administrative nightmare since we don't have a staff processing releases with extra time to add this info.

Considering the amount of freeloaders coming here making bogus applications hoping for an easy way in and completely ignoring every guide ever written here it would be a nightmare updating this info for every upload, and even if I would only update this info for approved members it would serve little to no purpose in the end. If there's an issue with a release I PM the user directly and get it sorted that way.

And there's also the aspect of privacy as we don't want every tiny detail about the members whereabouts to be logged. That would discourage a lot of people coming here in the first place.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jun 23, 2019 1:06 pm 
Reply with quote
FTP Access
Offline

Joined
Sun Feb 25, 2018 6:49 pm

Posts
282

Location
GMT+2 w/dst

Favourite OS
6.0.6001
Searching c++ doesn't work and complains about the search result being less than 3 characters.
Image

_________________
<!--Placeholder-->


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jun 23, 2019 2:34 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Fri Aug 18, 2006 11:47 am

Posts
12564

Location
Merseyside, United Kingdom

Favourite OS
Microsoft Windows 7 Ultimate x64
The + symbol is a reserved character and currently gets stripped out. I'll have to work on a way to keep this included in future, but for now it's not searchable.

_________________
Image

BetaArchive Discord: https://discord.gg/epK3r6A


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jun 23, 2019 8:29 pm 
Reply with quote
FTP Access
Offline

Joined
Sun Apr 08, 2018 1:07 am

Posts
182

Location
Buffalo, New York

Favourite OS
All Windows versions
mrpijey wrote:
Snip

Yeah, that's what I thought. That suggestion would just cause stress for the admins, as they would have to update every page containing the stuff I explained. But maybe you wouldn't have to update those statuses yourself. You could maybe add something that can automatically update the status to "uploaded", "rejected", or "pending" using a JavaScript file? Then you wouldn't have to manually update the code for those pages? But other than that, I figured my suggestion was a bad idea from the start. Plus, not everyone would really need to know about everything someone contributes to the FTP, whether it's been approved or not.

_________________
[TUT] Install Windows Whistler without setting BIOS date

Image


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jun 23, 2019 9:44 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
The issue isn't the code to update the status, the issue is the status itself. Since for every release I would need to set this status and change it several times. It's too much work for a feature that isn't really needed. We are going to discuss a new way of applying for FTP access etc, perhaps then it can be more automated in some way, but in the end I am still alone doing all the grunt work, and I don't want to waste the time sitting and updating databases back and forth.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 1:52 pm 
Reply with quote
Donator
Offline

Joined
Sun Jun 19, 2016 5:28 pm

Posts
36

Favourite OS
Windows NT 4.0
Some suggestions:

1. Use ISO 8601 date format.
There are so many date formats which can really be a problem in many scenarios, so given the fact that the database is a new long-term project, it will be best for all of us to go with the standards.

2. Attach file checksums to the database.
Same as above: use current standards, so no MD4/MD5/SHA1, but SHA-256 as absolute minimum, and I strongly press to use SHA3-512.

Personally I would do it like this:
SHA-1 - just for reference only (!). SHA-1 is not considered secure in most scenarios and is not recommended to use since 2010. Even the Windows Update under Windows 7 since June 2019 will need a patch which makes use of SHA-2-256 possible (later versions of Windows use it by default). But let's attach it for cases when somebody is searching for a particular file via web search engine and has, for example, the MSDN hash (which is SHA-1)
SHA-2-256 - as it is current minimum. Validated since 2001, currently in wide use. I'm not a big fan of that function, I believe that the world should switch to SHA-3 exactly at the time when they switched to SHA-2. But anyway, it is (for now) secure.
SHA-3-512 - as it is long term, high security standard, predicted to be used for many years. Keep in mind, that it has completely different internal architecture, so advances in cryptanalysis of SHA-2 will not affect this function.

3. Attach digital signature of the files.
You can sign the release package or only the file containing checksums. Both ways are acceptable, the second one takes much less time to do it.

4. Split "size" filed to two fields.
One would contain the size in bytes, the other one in gigabytes. In my opinion, the "bytes" version is totally sufficient.

5. Add unique ID for each entry.
Let every entry has it's unique ID to make it easy to refer in posts.


All of the above operations can be automated and all of them will have positive impact in terms of security and usefulness. I can help you in accomplishing this task, especially if you want to know more about topics in security area, I can explain you those in deep.


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 1:59 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Fri Aug 18, 2006 11:47 am

Posts
12564

Location
Merseyside, United Kingdom

Favourite OS
Microsoft Windows 7 Ultimate x64
1. We store the time/date in UNIX timestamp format, so the visible format is easy enough to change if needed.
2. We're planning to do this in future.
3. We're planning on signing individual files already.
4. We already list the file size in both bytes and KB/MB/GB on the release page.
5. Each release has a unique ID, we just don't display it on the page. It is in the URL.

_________________
Image

BetaArchive Discord: https://discord.gg/epK3r6A


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 2:13 pm 
Reply with quote
Donator
Offline

Joined
Sun Jun 19, 2016 5:28 pm

Posts
36

Favourite OS
Windows NT 4.0
Andy wrote:
1. We store the time/date in UNIX timestamp format, so the visible format is easy enough to change if needed.

I know this is generally hard topic, but I believe that ISO format is more wildly used and more readable.

Andy wrote:
4. We already list the file size in both bytes and KB/MB/GB on the release page.

Yes, but put it to separate field (it's database normalization thing).

Andy wrote:
5. Each release has a unique ID, we just don't display it on the page. It is in the URL.

So please consider displaying it on the page.


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 2:16 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Fri Aug 18, 2006 11:47 am

Posts
12564

Location
Merseyside, United Kingdom

Favourite OS
Microsoft Windows 7 Ultimate x64
As I say, format can be shown however you need to. We don't have nor save the granularity of time/date format down to seconds because we simply don't have it.

It's easy to convert from bytes to GB, and would be considered duplicate data to store both.

The unique ID isn't a very friendly format, but I'll discuss it with mrpijey.

_________________
Image

BetaArchive Discord: https://discord.gg/epK3r6A


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 2:17 pm 
Reply with quote
Donator
Offline

Joined
Sun Jun 19, 2016 5:28 pm

Posts
36

Favourite OS
Windows NT 4.0
That sounds fine, thanks :)


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 3:11 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
vareu wrote:
Some suggestions:

2. Attach file checksums to the database.
Could be done, but that would also mean that hashes would need to be recalculated for the whole BA archive. Again. Got one word for this: NO. Not at this time at least, and not in the foreseeable future. But yeah, we might add the additional hashes, but that also means it will take much longer to process releases.

vareu wrote:
3. Attach digital signature of the files.
You can sign the release package or only the file containing checksums. Both ways are acceptable, the second one takes much less time to do it.
And how do you suggest we do this? We use RAR files which does not support digital signatures afaik, and that would also require something better than a self-signed signature... Expensive.

vareu wrote:
5. Add unique ID for each entry.
Let every entry has it's unique ID to make it easy to refer in posts.
We already have this, a unique UUID number which is presented in the URL of the release. If you want to refer to a release do it by referring to this URL. Then people have see all about it easily. Use the URL, that's why it's there.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 4:02 pm 
Reply with quote
Donator
Offline

Joined
Sun Jun 19, 2016 5:28 pm

Posts
36

Favourite OS
Windows NT 4.0
mrpijey wrote:
Could be done, but that would also mean that hashes would need to be recalculated for the whole BA archive. Again. Got one word for this: NO. Not at this time at least, and not in the foreseeable future. But yeah, we might add the additional hashes, but that also means it will take much longer to process releases.

It can be done using PowerShell - Get-FileHash - and do it recursively for the entire archive. Just one script.

mrpijey wrote:
And how do you suggest we do this? We use RAR files which does not support digital signatures afaik, and that would also require something better than a self-signed signature... Expensive.

No, do it just with GPG/Kleopatra with self-generated key which will be published on the forum and some keyserver like pgp.mit.edu. Again, this can be done recursively for the entire BA archive.

mrpijey wrote:
Then people have see all about it easily. Use the URL, that's why it's there.

I was just talking about showing the ID on each release site, that's all.
File number: XXX - just like in the library.


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 4:31 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
vareu wrote:
It can be done using PowerShell - Get-FileHash - and do it recursively for the entire archive. Just one script.
I am talking about the archives themselves and the contents. And even if we do it only on the releases it would still be 100TB+ data to be read and hashed. A lot of strain on the hardware for no beneficial reason. Security-wise I understand why SHA-1 etc is bad, but these are file hashes we're talking about. For that it's just fine.

vareu wrote:
No, do it just with GPG/Kleopatra with self-generated key which will be published on the forum and some keyserver like pgp.mit.edu. Again, this can be done recursively for the entire BA archive.
I don't see the benefit of this really. Why would this be useful? I would see benefit with it if the archive itself could be signed, but unless we start using EXE files we can sign with a digital signature I don't see any benefit for this. Most members don't even know what GPG or Kleopatra is or how to use it.

vareu wrote:
I was just talking about showing the ID on each release site, that's all.
File number: XXX - just like in the library.
So we would need a secondary numbering system to keep track of and index. Two unique identifiers... that would add a lot of extra work for no particular benefit except for members unable to paste a link? Also you don't go to the library to ask for "book number 2395487234", you ask for it by author and title, or by ISBN number. Libraries don't catalogue their books by a simple integer number. Just link to the release, if you already know which release you refer to in the database then just link to it directly.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 5:22 pm 
Reply with quote
Donator
Offline

Joined
Sun Jun 19, 2016 5:28 pm

Posts
36

Favourite OS
Windows NT 4.0
mrpijey wrote:
I understand why SHA-1 etc is bad, but these are file hashes we're talking about. For that it's just fine.

mrpijey wrote:
I don't see the benefit of this really. Why would this be useful?

To protect against intentional modification by rogue third-party - no matter if on data at rest or in transit. Keep in mind that FTP does not provide any guarantee for data integrity and confidentiality, so files can be modified while in transit. And then you can't say that SHA-1 is fine, because even Microsoft is updating it's Windows 7 update mechanism to support SHA-2. Only signed files or signed checksum files can assure high level of security. For such massive database it's important to be able to validate integrity of all files, with the ability to exclude intentional modification of either the files or the checksums. And that's where digital signatures are helpful.


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 6:40 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
It would be quite difficult to modify a large rar-file in a mitm-attack, and the hashes are on the BA FTP so members can compare the release against that. The FTP uses implicit SSL, the RAR files are locked against changes and the hashes would all change if there are any changes.

Because Microsoft updates its systems doesn't mean SHA-1 is 100% unusable for other purposes. It's a vast different between a multibillion company trying to protect their update mechanism for millions of people using their software and BetaArchive providing simple checksum verification for a bunch of RAR-files. What you suggest is simply overdoing it, like requiring fingerprint authentication against the BA server to grab Monkey Island 2 from the FTP... just not necessary. If you think about it, not even Microsoft offers the level of checks we have, since we have everything archived, with provided checksums, signature stamp in the RAR-file etc. Microsoft just pushes you an ISO-file or EXE-file without any checksums for the most part.

A mitm-attack is extremely unlikely, and even if it would happen it would be beyond our control anyway if the user logs in and doesn't react to a faulty SSL signature. All the releases themselves can be verified against the provided checksum files. And there's only one person on all of BA that has write access to the BA archive. And we have offline backups that are not accessible by any computer.

The amount of work required would just not be worth it in this case, and few people would ever know enough to recognize a mitm attack and know how to deal with it.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 7:23 pm 
Reply with quote
Donator
Offline

Joined
Sun Jun 19, 2016 5:28 pm

Posts
36

Favourite OS
Windows NT 4.0
You are right about implicit SSL, so the point of data being tapered in transit is not valid. But the possibilities of file being silently modified in case of breach, or even MITM when user is logging on, are still valid, so it is advised to have checksum files signed, because when attacker can modify the RAR archive, then he can also easily replace it's checksum. That way checksums provide only the ability to validate file integrity, not it's authenticity. As a result, there is no way to tell if file content is the same as it was in the time of publishing. Timestamps can also be altered without a notice. Moreover, in the advent of BA Database, the checksums and even digital signatures for them can be put in that database. This is not a lot of work, the entire thing can be automated. Yes, it will take hardware resources, but from the human perspective it is doable with one script.

And no, this has nothing to do with "overdoing" as you said, this is a common practice if software world, for example in Linux Distributions, where checksums are signed using Project's Release Key. Even projects like PuTTY or Notepad++ do it. If you want to provide high quality stuff, then such basic thing like assuring authenticity is a must.

Microsoft is signing it's executables using "Microsoft Authenticode" which you can check in file properties. Hashes for ISO's are distributed on my.visualstudio.com website, although that's true that they are not signed, but at least are on a different server.


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 7:58 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
Can he also replace the checksums on my offline backup drives? And even, even if someone could edit the checksums on the main FTP (which is unlikely, as no FTP account on BA has that permission), how would your suggestion prevent any of that anyway? It wouldn't be detected until you do a full verification of the entire archive... so in the end, still not useful. The only way it would be detectable would be if

1: Each archive was signed and verified upon unpacking. So an autoextracting EXE with signature, and it would halt and stop if a bad signature was detected. Not usable, and it would actually _increase_ the risk just in case the server was infected with something that attacks executables. And it would also not work on anything but Windows.

2: A completely custom client system where all downloads are automatically verified upon download, and unlocked. Not feasable at all.

3: No one can access the files, period. We shut down the FTP. Yeah.......

And again, unwanted changes would require so much access to the system that it would be detected. Again, only one single person has that kind of access to the archive. No FTP accounts have write access, nor is the server hosting the files open to the public. All transfers between the file server and BA hosting server is done through an encrypted VPN, and the hosting server has only read access to the files... What you paint up in a scenario so unlikely that even if someone would physically get access to my file server and change the files I would still have a backup I could kickstart in the matter of minutes and restore everything.

Given all of this I still don't see any need to do what you say. All the release hashes are stored in the database as well. And again, if a bad file is detected it can be restored from the backup. Each release also has parity data stored with it (not accessible by any users), which is also backed up. Sure, there are extreme circumstances where a damaged file could slip through and be archived or backed up in such a way that restoration would be impossible, but that's a risk we can live with. Especially with the resources we have. For the end user your suggestions would not help at all, since most users wouldn't even be able to realise that an archive was modified until it was too late. When that happens it gets reported, I check it and I fix it. Having the checksums signed would not prevent any of that happening, and I would still need to get a report about it and still fix it.

As for the more technical errors you can get there are again, offline backups to a server that has no Internet access whatsoever, ReFS (which we are moving to), and parity files to recover any bit rot or archive file errors etc. All individual rar files gets checksummed, as well as the whole release. All of which is put into the database.

You have weigh in a lot of factors when deciding on security. Having too much security is not a good thing, and you have to weigh the cost against the benefits. In this case, I don't see how signing the release checksums would help me in any way to prevent any problems with the releases, nor prevent the unknowing member from detecting any changes beyond the errors RAR throws up during unpack if the archive is modified, or the checksum files being mismatched against the copy on BA, the database or my backups. If anyone managed to gain that kind of access to the files so they can change all that, then they can also change the signature of the release, therefore making all of this completely useless.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 8:08 pm 
Reply with quote
Donator
Offline

Joined
Sun Jun 19, 2016 5:28 pm

Posts
36

Favourite OS
Windows NT 4.0
You are not taking into consideration bugs in software which you are using, but because you totally missing the point I'm making, I can only suggest to educate yourself about PGP/GPG signatures - thing which is really easy, free and provide required level of protection. It shouldn't take longer than the time you allocated for writing this post. Then we can talk about this later.

Greetings.


Top  Profile
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 8:41 pm 
Reply with quote
Administrator
User avatar
Offline

Joined
Tue Feb 12, 2008 5:28 pm

Posts
7935
We're not missing any points, we just don't see any benefits of implementing what you're suggesting. I am very much aware of PGP/GPG signatures as I use it on a daily basis, and I discarded the idea for BA use for the reasons I've told you already. The level of intrusion required to do the alterations you suggest would make the entire security chain useless as all levels of security can then be altered, everything from the archive files themselves all the way to the databases designed to hold all the keys etc. And it would not be beneficial for users as most of them would not know what to do with it anyway. With good enough access you could simply alter the keys to match anyway, and none of it would be detected until the damage is done. The system we have in place works well for the setup we have. Once we implement web downloads in the future your suggestions might be better since we can then much easier add verification and automation to it, but FTP is not designed to facilitate this kind of functionality. You suggested changes to prevent two things, a mitm attack and unlawful changes to the source files, both are protected as well as it can with the current setup.

I am not saying your suggestions are bad. They are sound, but the cost, time and effort maintaining it isn't worth it for our current setup.

As for your other suggestions they will be taken into consideration. Some of it is already in the works, others we might implement in the future.

_________________
Image
Official guidelines: The Definitive Guide to BetaArchive :: Abandonware
Tools: Alcohol120% (Portable) :: DiscImageCreator
Listings: BetaArchive Database (beta)
Channels: Discord :: Twitter


Top  Profile  WWW
 PostPost subject: Re: BetaArchive Database Suggestions & Bug Reports        Posted: Sun Jul 14, 2019 11:24 pm 
Reply with quote
Donator
User avatar
Offline

Joined
Fri May 14, 2010 1:29 pm

Posts
865

Location
Southern Germany

Favourite OS
IRIX 5.3
With all the recent bullshit bugs in PGP and the keyservers, I would advise against doing anything with pgp/gpg until the dust has settled and, who knows, maybe a successor emerges or something.

And about all those hashes and talk about "security" and "MITM attacks on BA" and stuff, that is just overly paranoid. Even with SHA-1 it is still hard to generate a hash collision (2^68 SHA-1 calculations for a chosen-prefix collision, with dollar-costs in the 6-digit or 7-digit range), and I doubt anyone would so much time & energy to, say, flip a few bits at the end of some random RAR file on BA, especially since RAR would immerdiately detect that and refuse to unpack the file.

I would say it's not worth the trouble right now, and the cost far outweighs any theoretical benefits. SHA-1 is still good for quick file identification (heck, even the first 10 digits of the SHA-1 checksum would be enough to catch any transfer errors), and signatures do not add any benefits at all

_________________
I upload stuff to archive.org from time to time. See here for everything that doesn't fit BA


Top  Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 121 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next




Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

All views expressed in these forums are those of the author and do not necessarily represent the views of the BetaArchive site owner.

Powered by phpBB® Forum Software © phpBB Group

Copyright © 2006-2019

 

Sitemap | XML | RSS