Re: [Slackbuilds-users] MD5 hash sums
Each SlackBuild archive is signed by the SBo devs, so any modifications on the server (or in-between) would fail subsequent verification. In that case it's the GPG signature that you trust to verify the .info file contents (and all the rest of the SlackBuild stuff), not the MD5 sum or whatever else is inside it. Sorry, the question I had in mind was about MD5 sums inside it. Seems kind of strange that SlackBuild archive is protected by GPG signature, but the actual source tarball is not signed and is protected by (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM the source tarball itself, since some DOWNLOAD links are provided trough plain HTTP? GnuPG FAQ quote (https://gnupg.org/faq/gnupg-faq.html#define_sha): SHA-224, 256, 384, or 512: This is a massively-overhauled SHA-1 which generates larger hashes (224, 256, 384, or 512 bits). Right now, these are the strongest hashes in GnuPG. vs MD5 is a 128-bit cryptographic hash function invented by Ron Rivest (the ‘R’ of ‘RSA’) in the early 1990s. For many years it was one of the standard algorithms of the field, but is now completely obsolete. For that reason, MD5 is not supported by GnuPG. Wouldn't it be better to use, say, SHA512 instead? ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
[Slackbuilds-users] Metacharacters in package names
Hi, I have written a short script that lists built packages on which no other package depends: https://github.com/ChrisAbela/apex/blob/master/apex.sh It assumes that the user is using sbopkg and relies on rigorously maintained queue files. The script wrongly lists tolua++ as an "apex package" as egrep (at line 52) interprets the "+" metacharacter. May I suggest to avoid metacharacters in package names. In this case toluapp would have been a better choice, as per homepage: https://github.com/LuaDist/toluapp. Thanks to all that maintain scripts. You make Slackware a better experience. Chris Abela ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] Metacharacters in package names
Hi, On Wed, 22 Aug 2018 22:13:26 +0200 Chris Abela wrote: > The script wrongly lists tolua++ as an "apex package" as egrep (at > line 52) interprets the "+" metacharacter. May I suggest to avoid > metacharacters in package names. In this case toluapp would have been > a better choice, as per homepage: https://github.com/LuaDist/toluapp. I'd say that, even if special characters are avoided in package names, you should sanitize/filter the inputs accordingly to where they are used. IMHO package renaming should only be done in really pressing cases, as there are other things which don't work without friction then (upgrading the package for example). Furthermore, each artificial restriction will be a requirement soon, as other things will depend on it. This could be a good solution for the problem in your script: https://stackoverflow.com/a/16951928 Kind Regards Ruben ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] Metacharacters in package names
On 8/22/18, Ruben Schuller wrote: > > This could be a good solution for the problem in your script: > https://stackoverflow.com/a/16951928 My eyes! The goggles, they do nothing! Using grep instead of egrep would also be a solution to this issue. grep can do everything (or maybe almost everything?) egrep does, just needs extra \ in front of some of the metacharacters to make them meta. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] MD5 hash sums
On 22/08/2018 15:55, t...@airmail.cc wrote: Each SlackBuild archive is signed by the SBo devs, so any modifications on the server (or in-between) would fail subsequent verification. In that case it's the GPG signature that you trust to verify the .info file contents (and all the rest of the SlackBuild stuff), not the MD5 sum or whatever else is inside it. Sorry, the question I had in mind was about MD5 sums inside it. Seems kind of strange that SlackBuild archive is protected by GPG signature, but the actual source tarball is not signed and is protected by (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM the source tarball itself, since some DOWNLOAD links are provided trough plain HTTP? unless you are running over public wifi or internet cafe, a MITM attack on a source gz is less likely than someone breaking in to your hoise/business and planting malware on your pc/laptop. It would mean your ISP was compromised, in which case you have bigger issues to worry about than sourcde code frome some sites being changed on the fly. When you bear in mind that source code is usually compressed, it is not so easy to change bits while keeping the md5 sum the same and also not causing the archive to be un-openable because of the changes.- the changes would break the checksums inside the gz file format. GnuPG FAQ quote (https://gnupg.org/faq/gnupg-faq.html#define_sha): SHA-224, 256, 384, or 512: This is a massively-overhauled SHA-1 which generates larger hashes (224, 256, 384, or 512 bits). Right now, these are the strongest hashes in GnuPG. vs MD5 is a 128-bit cryptographic hash function invented by Ron Rivest (the ‘R’ of ‘RSA’) in the early 1990s. For many years it was one of the standard algorithms of the field, but is now completely obsolete. For that reason, MD5 is not supported by GnuPG. Wouldn't it be better to use, say, SHA512 instead? ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/ ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] MD5 hash sums
On 8/22/18 9:55 AM, t...@airmail.cc wrote: >> Each SlackBuild archive is signed by the SBo devs, so any >> modifications on the server (or in-between) would fail subsequent >> verification. In that case it's the GPG signature that you trust to >> verify the .info file contents (and all the rest of the SlackBuild >> stuff), not the MD5 sum or whatever else is inside it. > > Sorry, the question I had in mind was about MD5 sums inside it. Seems > kind of strange that SlackBuild archive is protected by GPG signature, > but the actual source tarball is not signed and is protected by > (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM > the source tarball itself, since some DOWNLOAD links are provided trough > plain HTTP? Sources are not protected by us. We do not provide the MD5 sum as any sort of security measure, it shouldn't be treated as one. We have no agency over upstream sources, and we purposefully do not host them, so we cannot provide any signature or sum that could be considered a token of security. -- Erik signature.asc Description: OpenPGP digital signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] MD5 hash sums
On 08/23/2018 12:55 AM, t...@airmail.cc wrote: > Sorry, the question I had in mind was about MD5 sums inside it. Seems > kind of strange that SlackBuild archive is protected by GPG signature, > but the actual source tarball is not signed and is protected by > (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM > the source tarball itself, since some DOWNLOAD links are provided trough > plain HTTP? Let's say the user has a SlackBuild + .info file, both of which have been signed by the SBo dev team and are authentic (thus including the MD5). The assumption here is that the maintainer actually checks signatures upon downloading (and that upstream devs even sign in the first place), so the stuff in the .info is "safe". Now the user goes to download the source listed in .info, and unbeknown to them it has been maliciously tampered with (either on the server or MITM, so either TLS or not, it doesn't matter). The MD5 of that altered archive will not match the authentic MD5 found in the .info file. For an attacker to change the upstream source archive without changing the MD5 requires a 2nd preimage attack, which as far as I understand is not computationally feasible at present. This is different to a much simpler collision attack, where the attacker generates two _new_ archives with new (and matching) MD5s. So, as long as SlackBuild maintainers are actually verifying the signatures on source archives and not blindly trusting checksums (of any variety) published on upstream websites, then using MD5 in this way seems OK. That said, I do think that it would be safer practice to just use a stronger hash function anyway (https://blake2.net/ ?), as things can change suddenly (who knows what's around the corner). -- Dave ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] MD5 hash sums
On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy wrote: > For an > attacker to change the upstream source archive without changing the MD5 > requires a 2nd preimage attack, which as far as I understand is not > computationally feasible at present. This is different to a much simpler > collision attack, where the attacker generates two _new_ archives with > new (and matching) MD5s. > The download files do not necessarily have to be tar archives, and in some cases (generally those with multiple download files and therefore multiple checksums), individual files can be included for download. Intentional PDF collisions have been around for ages (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a SlackBuild includes some documentation as a download link, and the upstream server has since been compromised, a user could definitely be stuck with a malicious file even if the SlackBuild maintainer did everything right and verified upstream signatures. It is probably more difficult to generate tarballs with collisions but I'm guessing it isn't quite as difficult as we're pretending it is, and it's irrelevant since unzipped files can be passed as download links. Simply put, this is bad security. Anyone who disagrees doesn't understand the problem. Can't we just add an optional sha256sum in the .info file and maintainers can gradually add these checksums to their SlackBuilds, targeting some point in the future that these fields will be required (and possibly the md5s retired)? -T3slider > ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] Metacharacters in package names
On 8/22/18, Ruben Schuller wrote: This could be a good solution for the problem in your script: https://stackoverflow.com/a/16951928 My eyes! The goggles, they do nothing! Using grep instead of egrep would also be a solution to this issue. I confess that I had to look up that meme. I understand that you wanted to express your dislike on the previous solutions kindly offered by the previous interlocutor. I don't like it as well. My preferred solution would be to distract the author of this application and plug out the '+' key from his/her keyboard. Or else I can rely on the undocumented and exclusive pkgtool feature to rename installed packages on the fly using the mv command: mv /var/log/packages/tolua++ /var/log/packages/toluapp (and prove once again that Slackware is unbreakable). There are many solutions but my intention was not to request assistance on my script. The script is just a cosmetic addition to sbopkg anyway. My intention was to solicit your reconsideration on the inclusion of metacharacters in package names. They are a nuisance, ugly and they break things. Which characters are acceptable? Would you also accept white spaces and semi-colons? Chris Abela ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
