Re: [arch-general] Stronger Hashes for PKGBUILDs
On Mon, May 14, 2018 at 11:01:57AM -0400, Eli Schwartz via arch-general wrote: > We're currently in feature freeze for pacman 5.1 > > Anyone who hopes to have b2sum support in *future* versions of pacman, > would be well advised to come across as a person seeking to extend > support for the current crop of common hashing algorithms, not someone > pushing b2sum because "secure all PKGBUILDs". > > For this reason, it would probably be useful to see coreutils support > more than one cherry-picked modern hashing algorithm. I'm not really > caring which ones those are, but then I'm also perfectly happy with > sha256/sha512 (which are both of them great algorithms which work > perfectly fine). > > So I'm uninterested in the bikeshed on general principle, and only > vaguely interested inasmuch as having more tools and more diversity in > the future would probably be interesting and/or useful. But I can find > lots of arguments for and against all the SHA3 candidates, some of them > rather bitter, so I see no reason to take sides. I agree... But I think that trying to identify the best algorithm is a waste of time because the only important feature is whether a given hash algorithm has been broken (in the sense of generating collisions). Everything else (performance, hash size, etc) is completely irrelevant for makepkg use... It would make sense to include B2B/SHA3 support in makepkg when we start seeing updtreams provide these hashes. Currently, AFAIK the only "upstream" doing that is Gentoo in their Manifests. Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 05/14/2018 10:48 AM, Leonid Isaev via arch-general wrote: > On Mon, May 14, 2018 at 11:23:39AM +0100, Ralph Corderoy wrote: >> Hi Eli, >> >>> Maybe you could ask the coreutils developers whatever happened to >>> implementing Keccak checksumming tools. >> >> SHA-3? Have you see >> https://www.imperialviolet.org/2017/05/31/skipsha3.html >> I've also seen suggestions that the Keccak team push Kangaroo Twelve >> these days over SHA-3 due to SHA-3's comparative slowness. > > Of course, none of this is relevant for the present thread... We're currently in feature freeze for pacman 5.1 Anyone who hopes to have b2sum support in *future* versions of pacman, would be well advised to come across as a person seeking to extend support for the current crop of common hashing algorithms, not someone pushing b2sum because "secure all PKGBUILDs". For this reason, it would probably be useful to see coreutils support more than one cherry-picked modern hashing algorithm. I'm not really caring which ones those are, but then I'm also perfectly happy with sha256/sha512 (which are both of them great algorithms which work perfectly fine). So I'm uninterested in the bikeshed on general principle, and only vaguely interested inasmuch as having more tools and more diversity in the future would probably be interesting and/or useful. But I can find lots of arguments for and against all the SHA3 candidates, some of them rather bitter, so I see no reason to take sides. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Mon, May 14, 2018 at 11:23:39AM +0100, Ralph Corderoy wrote: > Hi Eli, > > > Maybe you could ask the coreutils developers whatever happened to > > implementing Keccak checksumming tools. > > SHA-3? Have you see > https://www.imperialviolet.org/2017/05/31/skipsha3.html > I've also seen suggestions that the Keccak team push Kangaroo Twelve > these days over SHA-3 due to SHA-3's comparative slowness. Of course, none of this is relevant for the present thread... Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
Hi Eli, > Maybe you could ask the coreutils developers whatever happened to > implementing Keccak checksumming tools. SHA-3? Have you see https://www.imperialviolet.org/2017/05/31/skipsha3.html I've also seen suggestions that the Keccak team push Kangaroo Twelve these days over SHA-3 due to SHA-3's comparative slowness. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 05/13/2018 08:11 PM, Leonid Isaev via arch-general wrote: > On Sun, May 13, 2018 at 08:19:19PM +0200, Neven Sajko via arch-general wrote: >> On 13 May 2018 at 20:11, Neven Sajko wrote: >>> I do agree that using md5 is absurd, ... >> >> To clarify, md5 *is* unsecure and is even slower or not significantly >> faster than hashes from the Keccak and BLAKE2 families; using >> signatures would be a plus but signatures are not an argument for md5. > > It is trivial to enable blake2 support in makepkg using b2sum(1) from the > coreutils package. Currently, I only saw gentoo using it but I didn't do > proper research on this... Maybe you could ask the coreutils developers whatever happened to implementing Keccak checksumming tools. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Sun, May 13, 2018 at 08:19:19PM +0200, Neven Sajko via arch-general wrote: > On 13 May 2018 at 20:11, Neven Sajko wrote: > > I do agree that using md5 is absurd, ... > > To clarify, md5 *is* unsecure and is even slower or not significantly > faster than hashes from the Keccak and BLAKE2 families; using > signatures would be a plus but signatures are not an argument for md5. It is trivial to enable blake2 support in makepkg using b2sum(1) from the coreutils package. Currently, I only saw gentoo using it but I didn't do proper research on this... Yes, md5 is almost as good these days as crc32... It is ok if the sources are gpg-signed, but not on its own. Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 13 May 2018 at 20:11, Neven Sajko wrote: > I do agree that using md5 is absurd, ... To clarify, md5 *is* unsecure and is even slower or not significantly faster than hashes from the Keccak and BLAKE2 families; using signatures would be a plus but signatures are not an argument for md5.
Re: [arch-general] Stronger Hashes for PKGBUILDs
I do agree that using md5 is absurd, but putting effort into using sha-2 seems like a waste when Keccak and BLAKE2 are both faster and more secure than the old hashes. Regards, Neven
Re: [arch-general] Stronger Hashes for PKGBUILDs
The single most beneficial change would be adoption of The Update Framework, since it is resilient against all known issues with remote package management, regardless of pkg signers coming/going and whether HTTPS is used or not. It also has a nice protocol for handling key revocation.
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 05/10/2018 05:46 AM, Leonid Isaev via arch-general wrote: > In this regard, I don't understand why we need checksums at all? If upstream: > (1) signes source with GPG, it will take care of both integrity and > authenticity, so no need for hashes; > (2) doesn't provide signatures, rely on gzip/bzip2/xz CRC. It is not > cryptographically secure, but we don't need that anyway. > Hence, we can substantially simplify makepkg code... makepkg --skippgpcheck without checksum integrity this would potentially result in corrupted, malformed downloads that aren't caught. Also a check which tells you the file has a bad signature *because the download is malformed* is sort of a weird user experience, and it might not be obvious you should try redownloading. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Thu, 10 May 2018 03:46:34 -0600, Leonid Isaev via arch-general wrote: >GPG is not complicated at all. https://aur.archlinux.org/pkgbase/linux-rt/#comment-645504 SICR -- pacman -Q linux{,-rt{,-pussytoes,-securityink,-cornflower}}|cut -d\ -f2 4.16.7-1 4.16.7_rt1-1 4.14.34_rt27-1 4.14.29_rt25-1 4.14.28_rt23-1
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Thu, May 10, 2018 at 10:06:08AM +0200, NicoHood wrote: > I really like you effort on stronger hashes. I totally aggree with you > that we need those, if we can't have GPG signatures by the maintainers. > Hashes just help in less usecases than GPG signatures, of course, but > they do. Currently, about 55% of [core] and 31% of [extra] packages make use of validpgpkeys. In [community] it should be even less. So, it is still a long way to go while all PKGBUILDs use GPG-verified sources... I agree with others that using a single sha256sum instead of md5sum offers questionable security benefit, but at least it protects against future tampering with the src by an attacker who knows about MD5 collisions. > Unfortunately I made the experience, that this discussion is useless > here and you rather start helping with GPG signatures for every package. > If you want to put effort into this topic, which I really appreciate, > please directly go for GPG signatures, otherway it will be just a > frustrating discussion for you, sadly. There are only about 13% of packages in both [core] and [extra] that use MD5 -- a relatively small percentage. Yes, replacing those with a stronger hash is a stop-gap measure, but it involves no maintainance overhead. When you brought up this point last December, I didn't know that it is possible to have concurrent CRC and MD5 collisions (ar at least they are difficult to find). But since then, I did some homework and it indeed seems quite easy these days. Therefore, using MD5 is no better than having SKIP. In this regard, I don't understand why we need checksums at all? If upstream: (1) signes source with GPG, it will take care of both integrity and authenticity, so no need for hashes; (2) doesn't provide signatures, rely on gzip/bzip2/xz CRC. It is not cryptographically secure, but we don't need that anyway. Hence, we can substantially simplify makepkg code... > What I can recommend to you for this is to write to upstream projects > who don't use GPG signatures yet. Explain them why its important and > help them to improve their software release security. I made the > experience that quite a lot of projects did not know about the > importance of GPG or just never looked into it. Just a few refuse to use > GPG, leave that for now. What about upstreams, like PAM, who stopped signing their releases? From a developer point of view, it makes sense to not have a GPG key because it implies an additional responsibility of keeping it safe. Therefore, I understand people who don't signed their src archives. > As additional support you can use the GPGit guides as well as the > automated (same named) GPGit tool: https://github.com/NicoHood/gpgit > It will help new users to understand GPG and provide them an easy to use > tool to get started with GPG within a few minutes. Feedback for this is > appreaciated. I don't think it's needed. GPG is not complicated at all. The difficulty that prevents its widespread use lies with maintaining the key, and with that no guide can help... > I wish you all good luck, dont hesitate to contact me further if you > have any great ideas regarding GPG etc. Thanks, L. -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 05/10/2018 01:25 AM, Leonid Isaev via arch-general wrote: > On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote: >> I would just like to note that SHA-2 hashes are inferior to Keccak and >> to BLAKE2. So better not to spend effort migrating to SHA-2. > > Strength of various SHA hashes is a different topic. My only point was that > relying on md5 these days is like having no hashes at all or using the source > filename as a hash... > > And there should be no migration -- when a new version of a package is > released > or a rebuild happens, just update the *sums array. > > Cheers, > Hello Leonid Isaev, I really like you effort on stronger hashes. I totally aggree with you that we need those, if we can't have GPG signatures by the maintainers. Hashes just help in less usecases than GPG signatures, of course, but they do. Unfortunately I made the experience, that this discussion is useless here and you rather start helping with GPG signatures for every package. If you want to put effort into this topic, which I really appreciate, please directly go for GPG signatures, otherway it will be just a frustrating discussion for you, sadly. What I can recommend to you for this is to write to upstream projects who don't use GPG signatures yet. Explain them why its important and help them to improve their software release security. I made the experience that quite a lot of projects did not know about the importance of GPG or just never looked into it. Just a few refuse to use GPG, leave that for now. As additional support you can use the GPGit guides as well as the automated (same named) GPGit tool: https://github.com/NicoHood/gpgit It will help new users to understand GPG and provide them an easy to use tool to get started with GPG within a few minutes. Feedback for this is appreaciated. I wish you all good luck, dont hesitate to contact me further if you have any great ideas regarding GPG etc. ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
Op do 10 mei 2018 01:26 schreef Leonid Isaev via arch-general < arch-general@archlinux.org>: > On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote: > > I would just like to note that SHA-2 hashes are inferior to Keccak and > > to BLAKE2. So better not to spend effort migrating to SHA-2. > > Strength of various SHA hashes is a different topic. My only point was that > relying on md5 these days is like having no hashes at all or using the > source > filename as a hash... > Which is (still) pretty much the point of these hashes. With pacman these are *not* very important. The hashes are there for a quick check if the download is complete. Integrity is a job for PGP. Mvg, Guus Snijders >
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Wed, May 09, 2018 at 09:30:51PM +0200, Neven Sajko wrote: > I would just like to note that SHA-2 hashes are inferior to Keccak and > to BLAKE2. So better not to spend effort migrating to SHA-2. Strength of various SHA hashes is a different topic. My only point was that relying on md5 these days is like having no hashes at all or using the source filename as a hash... And there should be no migration -- when a new version of a package is released or a rebuild happens, just update the *sums array. Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 05/08/2018 10:38 PM, Eli Schwartz via arch-general wrote: > This is honestly a much better use of everyone's time. It is indeed a rare occurrence to see the uncommon common sense rear its lonely head from time to time... but comforting. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
I would just like to note that SHA-2 hashes are inferior to Keccak and to BLAKE2. So better not to spend effort migrating to SHA-2.
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Wed, May 09, 2018 at 12:31:39AM -0400, Eli Schwartz via arch-general wrote: > PGP keys are also far more likely to appear in multiple independently > verifiable locations, you can embed them in your DNS records, post them > on your blog, github profile, keybase.io proofs utilizing DNS as well as > social media linkages, email footer (and signed email history) to > establish a difficult-to-falsify history, or simply follow the PGP web > of trust. It is all true. But... if I care to only do "makepkg -g >> PKGBUILD", then I'm unlikely to follow web of trust, and if I'm going to scout mailing lists for email footers, I will also scout debian, gentoo, alpine and fedora repos for different hashes. That was my only point, but we are mixing policy and technical issues. If hashes are supposed to mean that I'm building the same source as the maintainer, then using only md5sums negate this because the source can be silently swapped using existing libraries, and attackers don't even need to know mathematics behind md5 collisions... I agree that using strong hashes alone does not address security of source distribution, but neither does HTTPS for instance. At least, with sha-2 hashes, point #3 of your previous email makes sense. Thanks, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 05/08/2018 11:53 PM, Leonid Isaev via arch-general wrote: >> - not any sort of security check at all, they're there for CRC purposes, >> and using strong CRC is security theater because the maintainer >> probably just blindly ran updpkgsums without checking anything at all >> so they generated very strong fake hashes -- come back when you have >> PGP[1] which is actually security > > In this case, even using gpg keys won't guarantee security because verifying a > key via a side channel is not much easier than the hash. I'm not sure what you mean. PGP is by its very nature very secure, you establish an ongoing relationship with the key holder and can verify many, many objects, like the entire release history instead of independently bootstrapping the TOFU (Trust On First Use) model with every new release. PGP keys are also far more likely to appear in multiple independently verifiable locations, you can embed them in your DNS records, post them on your blog, github profile, keybase.io proofs utilizing DNS as well as social media linkages, email footer (and signed email history) to establish a difficult-to-falsify history, or simply follow the PGP web of trust. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Tue, May 08, 2018 at 11:38:01PM -0400, Eli Schwartz via arch-general wrote: > When you say "still", that implies that there was any sort of effort to > change that in the first place... Fair enough :) I thought it's a slow natural process... > - not any sort of security check at all, they're there for CRC purposes, > and using strong CRC is security theater because the maintainer > probably just blindly ran updpkgsums without checking anything at all > so they generated very strong fake hashes -- come back when you have > PGP[1] which is actually security In this case, even using gpg keys won't guarantee security because verifying a key via a side channel is not much easier than the hash. > - actively dangerous as people think strong checksums equals security, > which makes them trust the sources even when they shouldn't; like > security theater except used as a justification for the other extreme Yes, but see [1] and [2]. At least with SHA hashes we are not so vulnerable. [1] http://cryptography.hyperlink.cz/2004/otherformats.html [2] https://www.mathstat.dal.ca/~selinger/md5collision > - better than nothing, and therefore very useful since it ensures that > you at least rebuilt the same thing the maintainer did No really, see just above. That is an old link, probably now forging .tar.gz files got much easier. > - very much security, because obviously the maintainer verifies sources > out of band, and checksums are their way of telling us what the > canonical sources are If (s)he does, then there will be multiple hashes, from different sources, no? > As extensively discussed in several mailing list and forum threads, the > best way to get security which everyone agrees on is to encourage > upstream developers to PGP-sign their sources. I've done quite a bit of > work on the existing TODO[1] which we have for implementing better PGP > checks (and HTTPS for both privacy and TLS endpoint verification), in > addition to providing the patchset[2] for makepkg (available in git > master and awaiting the 5.1 release) which allows verifying git(1) > signed commits/tags. Thanks for your work! I didn't know about those links, will check them out. But ok, I see your point... Thanks, L. -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 05/08/2018 10:08 PM, Leonid Isaev via arch-general wrote: > Hi, > > I'm intentionally using the title from Nov/Dec 2016 [0] to ease > googling. I decided to check the status of this, and there is still 325 > packages with only md5sums in [core] and [extra] (I didn't check [community]). > Below results are generated by the attached script... Is there anything I can > do (like sending reports to the Flyspray) to help convert those PKGBUILD's to > SHA hashes? When you say "still", that implies that there was any sort of effort to change that in the first place... It will be closed as WONTFIX. That's a maintainer choice, and there are differing opinions about whether stronger checksums are: - not any sort of security check at all, they're there for CRC purposes, and using strong CRC is security theater because the maintainer probably just blindly ran updpkgsums without checking anything at all so they generated very strong fake hashes -- come back when you have PGP[1] which is actually security - actively dangerous as people think strong checksums equals security, which makes them trust the sources even when they shouldn't; like security theater except used as a justification for the other extreme - better than nothing, and therefore very useful since it ensures that you at least rebuilt the same thing the maintainer did - very much security, because obviously the maintainer verifies sources out of band, and checksums are their way of telling us what the canonical sources are FWIW I agree with point #3, but I estimate there's zero chance of universal consensus, and would prefer not to see a failed crusade rile people up. Again. As extensively discussed in several mailing list and forum threads, the best way to get security which everyone agrees on is to encourage upstream developers to PGP-sign their sources. I've done quite a bit of work on the existing TODO[1] which we have for implementing better PGP checks (and HTTPS for both privacy and TLS endpoint verification), in addition to providing the patchset[2] for makepkg (available in git master and awaiting the 5.1 release) which allows verifying git(1) signed commits/tags. This is honestly a much better use of everyone's time. [1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/ [2] https://git.archlinux.org/pacman.git/log/?id=37a89e2fac704babbe3badf0d9df0d41ec622f6f&showmsg=1 -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Tue, May 08, 2018 at 08:08:31PM -0600, Leonid Isaev wrote: > [extra] > ... This list should also include "python-retrying". I should have grepped more carefully, sigh... -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Tue, May 08, 2018 at 08:08:31PM -0600, Leonid Isaev wrote: > [0] https://lists.archlinux.org/pipermail/arch-general/2016-December/042 Oops, this link should have been https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
Hi, I'm intentionally using the title from Nov/Dec 2016 [0] to ease googling. I decided to check the status of this, and there is still 325 packages with only md5sums in [core] and [extra] (I didn't check [community]). Below results are generated by the attached script... Is there anything I can do (like sending reports to the Flyspray) to help convert those PKGBUILD's to SHA hashes? Thanks, L. - Stats - Total: 325 [core]: 28 [extra]: 283 removed: 14 -- Repo breakdown -- [core] b43-fwcutter cracklib dmraid fakeroot filesystem flex hdparm ipw2100-fw ipw2200-fw libaio libgssglue libnsl librpcsecgss libsasl libusb licenses linux-atm nfsidmap nilfs-utils pam pcmciautils pptpclient reiserfsprogs sysfsutils usbutils which xinetd zd1211-firmware [extra] a52dec accounts-qml-module aiksaurus alsa-firmware alsa-lib antlr2 apricots archlinux-menus archlinux-themes-slim arptables aspell-de aspell-es aspell-fr aspell-nl assimp attica-qt4 autoconf2.13 automoc4 bigloo bird bluez-firmware bogofilter bootchart capi4hylafax celt celt0.5.1 chemtool chmlib claws-mail-themes compface convertlit convmv cpio cscope ctags cups-pdf cvsps cyrus-sasl dbus-sharp dbus-sharp-glib ddrescue dmapi docbook-mathml docbook-xml dotconf ebtables enscript exiv2 facile fakechroot festival ffcall freealut frozen-bubble fsarchiver gamin gconf-sharp gd gdome2 giblib giflib gnome-mime-data gnu-efi-libs gnu-netcat gob2 gtkglext gtkmathview guile1.8 gwaterfall habak hunspell-it hunspell-ro hwdetect hylafax hyphen-de hyphen-it hyphen-nl hyphen-ro icon-naming-utils ifplugd ijs ilmbase imap iniparser ipset jack java-commons-net1 java-gnumail java-inetlib java-jdepend java-jline java-resolver lablgtk2 ladspa lame libaccounts-glib libatasmart libcaca libcdaudio libdbusmenu-qt libdiscid libdmtx libfbclient libgadu libglade libglademm libid3tag libiec61883 libieee1284 libifp libirman liblangtag liblqr libmcrypt libmp3splt libmp4v2 libmpeg2 libmusicbrainz5 libnet libnss_nis libomxil-bellagio libshout libsignon-glib libstdc++5 libtommath libusb-compat libutempter libxkbui libxmi libyaml licq lockdown-ms lua51 lua52 luajson lzop metalog mjpegtools mkisolinux mkpxelinux mksyslinux mod_dnssd mozilla-common mp3splt mp3wrap mtdev munin musepack mysql-python mythes-de mythes-en mythes-fr mythes-it mythes-ro nawk ncftp npapi-sdk nss_ldap nss-mdns nuget openbabel openconnect openexr oxygen-gtk2 pam_ldap perl-appconfig perl-bit-vector perl-business-isbn-data perl-carp-clan perl-common-sense perl-config-simple perl-convert-binhex perl-crypt-openssl-rsa perl-crypt-passwdmd5 perl-crypt-ssleay perl-date-calc perl-digest-hmac perl-digest-nilsimsa perl-digest-sha1 perl-email-date-format perl-ev perl-event-execflow perl-extutils-depends perl-extutils-pkgconfig perl-fcgi perl-file-sharedir perl-file-which perl-gtk2-ex-formfactory perl-guard perl-html-parser perl-html-tagset perl-image-exiftool perl-ipc-system-simple perl-locale-gettext perl-log-log4perl perl-mail-spf perl-math-round perl-mime-lite perl-netaddr-ip perl-net-cidr-lite perl-net-ip perl-sdl perl-string-shellquote perl-sys-hostname-long perl-template-toolkit perl-term-readkey perl-text-iconv perl-tie-simple perl-timedate perl-xml-namespacesupport perl-xml-sax-base php-apcu php-apcu-bc pkgstats progsreiserfs protobuf psiconv psutils pulseaudio-alsa pyopengl pyqt4 pyrex pysmbc python2-configparser python-appdirs python-defusedxml python-fpconst python-geoip python-mccabe python-mpd python-nose python-notify python-soappy qrencode qt-assistant-compat raptor rasqal razor refind-efi rpcsvc-proto rpmextract sane sane-frontends sbc schroedinger scons sg3_utils signon-plugin-oauth2 signon-ui slim-themes snappy snarf sni-qt sonata sound-theme-freedesktop source-highlight spandsp speedtouch spice-protocol taglib telepathy-idle telepathy-salut testdisk tevent tftp-hpa thinkfinger tidy tree ttf-bitstream-vera unixodbc wicd xalan-java xerces2-java xerces-c xorg-fonts-100dpi xorg-fonts-75dpi xorg-fonts-alias xorg-fonts-cyrillic xorg-fonts-type1 xsane yajl zita-als
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Tue, Dec 27, 2016 at 6:09 PM, Leonid Isaev < leonid.is...@jila.colorado.edu> wrote: > On Mon, Dec 26, 2016 at 01:35:23PM +0100, NicoHood wrote: > > ArchLinux wants to KISS, so we should simply add stronger hashes instead > > of requiring the user to download two tools. Its quite a struggle to > > find a hash tool for windows anyways. > > How about Microsoft FCIV [1]? > > [1] https://www.microsoft.com/en-us/download/details.aspx?id=11533 Builtin Powershell commandlet: Get-FileHash: https://msdn.microsoft.com/en-us/powershell/reference/5.0/microsoft.powershell.utility/get-filehash Jürgen > > > Cheers, > -- > Leonid Isaev >
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/26/2016 07:35 AM, NicoHood wrote: >>> Yesterday I wanted to install ArchLinux on someone else computer. He >>> used Windows until now and had no gpg handy yet (it is really annoying >>> to install on windows). What is wrong with, say, Gpg4win? Okay, it is difficult to *trust* the software without any way of securely proving it itself hasn't been backdoored. Then again, how did *you* initially trust your Linux distribution? But I don't see why it would be especially difficult to *install* on Windows. >>> So we needed to verify the source otherwise. But there was no real >>> option as md5/sha1 is broken and his internet is too slow to download it >>> again via torrent. We did not install Arch then and I will send him my >>> sha512sum from my computer the next days where I did a torrent download. I was under the impression that sha1 works just fine, and will for a little while yet. Preimage attacks haven't been suggested to be feasible yet, to my knowledge. Though we should still move off sha1 simply because it is continually weakening and on its last legs (or already broken for some functionality), I am pretty sure your friend is safe... > ArchLinux wants to KISS, so we should simply add stronger hashes instead > of requiring the user to download two tools. Its quite a struggle to > find a hash tool for windows anyways. I am not overly familiar with the checksumming landscape in Windows-land, but I could have sworn all the common tools I found back in "the day" were capable of verifying a range of hash functions, much like coreutils as a set is capable of verifying a range of hash functions. Why do you need two tools? > Also the website should state from which person the signature is and > which fingerprint it uses. I still could not find this information > (otherwise I'd contact this person). Usually gpg tells you this automagically. :p Anyway, the key already has full trust from pacman-key, if you are verifying from an Arch system... also, the frontpage has a link[1] to the canonical master keys "for all Arch Linux purposes", which is how I initially verified the ISO signature as having a valid trust. (Do take caution to independently verify those signatures e.g. from the owner's personal website.) -- Eli Schwartz [1] https://www.archlinux.org/master-keys/ signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Mon, Dec 26, 2016 at 01:35:23PM +0100, NicoHood wrote: > ArchLinux wants to KISS, so we should simply add stronger hashes instead > of requiring the user to download two tools. Its quite a struggle to > find a hash tool for windows anyways. How about Microsoft FCIV [1]? [1] https://www.microsoft.com/en-us/download/details.aspx?id=11533 Cheers, -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 26.12.2016 13:12, NicoHood wrote: > So we needed to verify the source otherwise. But there was no real > option as md5/sha1 is broken I fully agree that using stronger hashes is generally a good idea, but please stop being ridiculous. > and his internet is too slow to download it > again via torrent. If you put your file at the location where the torrent client downloads the file to, it will detect this and check the existing file contents. Also, you know that torrent also uses SHA1 hashes internally, right? > The ArchLinux website connects via https. His mirror that he used did > not (http or ftp). https or not, the mirror admin has full control and can easily change the files. Please stop being pedantic and look at the bigger picture. Then you'd also see that it's much easier for an attacker to target our website and change the hashes there than trying to find an md5/sha1/filesize collision and then getting that file to you via one/all of our mirrors without having access to our servers. There are many trade offs and attack vectors when it comes to security. Don't focus on a single one. You could have improved a lot with all the dedication and time you put into these discussions if you worked on other things with more impact. Florian signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/26/2016 01:21 PM, Allan McRae wrote: > On 26/12/16 22:12, NicoHood wrote: >> >> >> On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote: >>> On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote: https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html i have a few things to add to this. the message digests at the download page for the .iso file, must change to sha256 and sha512 ones, or to a sha512 one. if an upstream does not sign the files, does not have https enabled, and/or refuses to take security and privacy seriously, sha512 must be used in the PKGBUILD files. in the cases of upstreams that use md5 and/or sha1 message digests, those will be added in a second ALGOsums= line under the sha512sums= line. if they use md5 and sha1, then sha1sums must be used for the second ALGOsums= line. >>> >>> Once again I must say thanks, fnodeuser. >>> >> >> Yesterday I wanted to install ArchLinux on someone else computer. He >> used Windows until now and had no gpg handy yet (it is really annoying >> to install on windows). >> >> So we needed to verify the source otherwise. But there was no real >> option as md5/sha1 is broken and his internet is too slow to download it >> again via torrent. We did not install Arch then and I will send him my >> sha512sum from my computer the next days where I did a torrent download. >> >> The ArchLinux website connects via https. His mirror that he used did >> not (http or ftp). So we had a real problem and there was no way to >> verify the source properly. Adding sha256 and sha512 would not cause >> more trouble but would be extremely helpful here. >> >> @Allan I think you are responsible for this if I am correct. Would you >> please be so kind and add sha256 sums to the download page? > > I have nothing to do with this. > > Also, is there even a theoretical case where a joint md5 and sha1 > collision has occured? > Oh sorry. ArchLinux wants to KISS, so we should simply add stronger hashes instead of requiring the user to download two tools. Its quite a struggle to find a hash tool for windows anyways. Also the website should state from which person the signature is and which fingerprint it uses. I still could not find this information (otherwise I'd contact this person). Going to add a bugreport instead: https://bugs.archlinux.org/task/52273 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 26/12/16 22:12, NicoHood wrote: > > > On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote: >> On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote: >>> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html >>> >>> i have a few things to add to this. >>> >>> the message digests at the download page for the .iso file, must change to >>> sha256 and sha512 ones, or to a sha512 one. >>> >>> if an upstream does not sign the files, does not have https enabled, and/or >>> refuses to take security and privacy seriously, sha512 must be used in the >>> PKGBUILD files. >>> >>> in the cases of upstreams that use md5 and/or sha1 message digests, those >>> will be added in a second ALGOsums= line under the sha512sums= line. if >>> they use md5 and sha1, then sha1sums must be used for the second ALGOsums= >>> line. >> >> Once again I must say thanks, fnodeuser. >> > > Yesterday I wanted to install ArchLinux on someone else computer. He > used Windows until now and had no gpg handy yet (it is really annoying > to install on windows). > > So we needed to verify the source otherwise. But there was no real > option as md5/sha1 is broken and his internet is too slow to download it > again via torrent. We did not install Arch then and I will send him my > sha512sum from my computer the next days where I did a torrent download. > > The ArchLinux website connects via https. His mirror that he used did > not (http or ftp). So we had a real problem and there was no way to > verify the source properly. Adding sha256 and sha512 would not cause > more trouble but would be extremely helpful here. > > @Allan I think you are responsible for this if I am correct. Would you > please be so kind and add sha256 sums to the download page? I have nothing to do with this. Also, is there even a theoretical case where a joint md5 and sha1 collision has occured?
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote: > On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote: >> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html >> >> i have a few things to add to this. >> >> the message digests at the download page for the .iso file, must change to >> sha256 and sha512 ones, or to a sha512 one. >> >> if an upstream does not sign the files, does not have https enabled, and/or >> refuses to take security and privacy seriously, sha512 must be used in the >> PKGBUILD files. >> >> in the cases of upstreams that use md5 and/or sha1 message digests, those >> will be added in a second ALGOsums= line under the sha512sums= line. if >> they use md5 and sha1, then sha1sums must be used for the second ALGOsums= >> line. > > Once again I must say thanks, fnodeuser. > Yesterday I wanted to install ArchLinux on someone else computer. He used Windows until now and had no gpg handy yet (it is really annoying to install on windows). So we needed to verify the source otherwise. But there was no real option as md5/sha1 is broken and his internet is too slow to download it again via torrent. We did not install Arch then and I will send him my sha512sum from my computer the next days where I did a torrent download. The ArchLinux website connects via https. His mirror that he used did not (http or ftp). So we had a real problem and there was no way to verify the source properly. Adding sha256 and sha512 would not cause more trouble but would be extremely helpful here. @Allan I think you are responsible for this if I am correct. Would you please be so kind and add sha256 sums to the download page? signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser wrote: > https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html > > i have a few things to add to this. > > the message digests at the download page for the .iso file, must change to > sha256 and sha512 ones, or to a sha512 one. > > if an upstream does not sign the files, does not have https enabled, and/or > refuses to take security and privacy seriously, sha512 must be used in the > PKGBUILD files. > > in the cases of upstreams that use md5 and/or sha1 message digests, those > will be added in a second ALGOsums= line under the sha512sums= line. if they > use md5 and sha1, then sha1sums must be used for the second ALGOsums= line. Once again I must say thanks, fnodeuser.
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 16/12/16 21:28, NicoHood wrote: > make sha512 the default Hey... guess what is still not happening?
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/16/2016 09:59 AM, Levente Polyak wrote: > On 12/16/2016 06:03 AM, Eli Schwartz via arch-general wrote: >> On 12/15/2016 08:35 PM, fnodeuser wrote: >>> what i said is that the users must check the integrity of the sources too. >>> it is not something that only the package maintainers must do. >>> the users must check the PKGBUILD files to compare message digests >>> and key fingerprints. >> >> You didn't say that. But now that you do say that, I can tell you that >> you are wrong. >> On no operating system, does anyone care about that. Only as a byproduct >> of source-based operating systems, do some (a small minority of) people >> even check that whether they care or not. >> >> The maintainers are maintainers because we trust them to be honest. And >> if they aren't honest, you are an absolute fool for thinking you can >> check the source in order to catch malicous modifications in the >> compiled binaries. > > I agree, there is no point why users _must_ check the integrity of > sources too. Essentially that's what a maintainer should do and you need > to trust a maintainer to some degree anyway. That doesn't mean nobody > should, if a particular group of users wants to, they can. But it is > certainly nothing users _must_ do. > In the AUR, it's of cause a bit different as you have much less trust in > an arbitrary maintainer and want to take a look at the PKGBUILD itself > and also figure out if that's really the right upstream. > And for those who want to check the sources, strong hashes are important. We are talking about integrity, not checksums. It was intended as checksum, fine. But the integrity ability of those hashes is ALSO highly important, not only the checksum ability. People can check all sources, not only the final (reproduceable) build. We all understood that it would not help the risk of downloading malicious sources in first place (TOFU). But it would help in the other (already multiple times described) scenarios. And that is what we are talking about. We are not talking about checksums. And it would not hurt in any way to make sha512 the default, **we can only benefit from that.** signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 16/12/16 11:35, fnodeuser wrote: > "With great power comes great responsibility." > -Uncle Ben I will not have misquotes on this mailing list!
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/16/2016 06:03 AM, Eli Schwartz via arch-general wrote: > On 12/15/2016 08:35 PM, fnodeuser wrote: >> what i said is that the users must check the integrity of the sources too. >> it is not something that only the package maintainers must do. >> the users must check the PKGBUILD files to compare message digests >> and key fingerprints. > > You didn't say that. But now that you do say that, I can tell you that > you are wrong. > On no operating system, does anyone care about that. Only as a byproduct > of source-based operating systems, do some (a small minority of) people > even check that whether they care or not. > > The maintainers are maintainers because we trust them to be honest. And > if they aren't honest, you are an absolute fool for thinking you can > check the source in order to catch malicous modifications in the > compiled binaries. I agree, there is no point why users _must_ check the integrity of sources too. Essentially that's what a maintainer should do and you need to trust a maintainer to some degree anyway. That doesn't mean nobody should, if a particular group of users wants to, they can. But it is certainly nothing users _must_ do. In the AUR, it's of cause a bit different as you have much less trust in an arbitrary maintainer and want to take a look at the PKGBUILD itself and also figure out if that's really the right upstream. > >>> sha256sums is plenty secure enough. So I assume the Firefox maintainer >>> uses that mega-file to validate the download, then uses updpkgsums to >>> update the current sha256sums rather than using copypasta on Firefox's >>> SHA512SUMS file. >> >> no. you will never use less secure than upstream. the best must be used >> to future-proof also. > > Yes, I will use less secure than upstream. What matters is that the > Firefox maintainer has proven to himself that he isn't releasing > maliciously-modified source code artifacts into the repositories. > Well I fully agree sha256 is plenty secure, if one has the resources and money (while money is resource :P) to maliciously collide sha256, then its definitively not the weakest point to attack. Also it is true that what really matters is the maintainer have proven to himself that he isn't releasing maliciously-modified source code artifacts. (not something particularly in response to Eli, but more a general statement:) While everybody must agree the only way to know if something _at_ the endpoint is something from the upstream author is only possible via authentication by a signature, we still have some possibilities if that's not the case. The concept for such is TOFU [0] (Trust on first use). To establish some trust from the maintainers point of view. One could f.e. do what Giancarlo (grazzolini) and also me is doing: Downloading the source over multiple _different_ routes/locations/hosts VPN/SSH and compare the results with each other. Additionally this is also the case where TLS adds something to the equation, it authenticates the endpoint itself via a "trusted" certificate authority (yes, we all know that CAs are far away from being perfect). Once the maintainer has proven to himself that trust was established as good as possible, a cryptographically secure integrity value will maintain _this_ trust level over its lifetime whenever the same must be re-fetched (f.e. rebuilds or AUR). Reproducible builds [1] will help to maintain trust but it won't serve as a replacement for a sloppy maintainer. In the beginning it won't even prevent that a backdoored package may get release, but it will serve to detect and find such when doing continuous reproducible tests from independent parties. At a further point in time one could integrate the RB concept into the release management or end-user installation process to prevent users possibly getting a malicious version because of a tampered source _after_ the upstream endpoint. For such, you will need something like staging a package until K out of N reproducibility sign-offs have happened, where N is the amount of "trustworthy" builders and K is the minimum number of matches out of this set (to avoid failure just because one builder is down, malfunctioning or itself compromised). Even this won't be easy, as you will need to carefully choose a set of independent trustworthy builders on the developer side. This would be the easy approach from a end-user point of view, while a power users may want to themselves choose who a trustworthy builder is. This would lead to the requirement to choose N and K during installation time, but as partial upgrades are not possible this will ultimately result in the inability to upgrade at all if the amount of matches of a single package is below K. Whatsoever, reproducible builds is a very complex but ongoing topic. I will bring this up in an independent way as its an independent area for itself. I just wanted to dump some info about it as sometimes one gets the feeling certain people think it will magically allow maintaine
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/15/2016 08:35 PM, fnodeuser wrote: > hello eli, > > you have misread and misunderstood a few things. No I haven't. But you've broken the response headers again in your reply. Using temporary email addresses on the mailing list is incredibly annoying; if you are that concerned about your privacy, you will be a lot happier simply unplugging from the internet altogether. It is kind of dishonest of you. ;) How do I know it is really you who sent that? Which is kind of ironic, considering the topic of this thread. /cc Allan, please blacklist this. > reread carefully all the messages about the subject, > and check the links in my second email. I did. That's how I formed my initial conclusions. > > i will write only about things that are not covered by the > previous messages. > >> Sure they're the same. It is the same underlying technology > > you have some studying to do about checksums and message digests. You have some studying to do about nitpicking over implementation details. Especially because your own Wikipedia links agree with me, although perhaps you just never read the article so you didn't realize. But since you are determined to ignore common sense, I'll ask you a question in response: If "checksums are not suitable for integrity verification", why do you care? MD5, heck CRC, works just as well as anything else for preventing data corruption, which apparently is all you think they are good for. >> Um, what? `pacman -Syu` does, in fact, check that every package is >> signed by a Developer or Trusted User whose key is in archlinux-keyring. > > what i said is that the users must check the integrity of the sources too. > it is not something that only the package maintainers must do. > the users must check the PKGBUILD files to compare message digests > and key fingerprints. You didn't say that. But now that you do say that, I can tell you that you are wrong. On no operating system, does anyone care about that. Only as a byproduct of source-based operating systems, do some (a small minority of) people even check that whether they care or not. The maintainers are maintainers because we trust them to be honest. And if they aren't honest, you are an absolute fool for thinking you can check the source in order to catch malicous modifications in the compiled binaries. >> sha256sums is plenty secure enough. So I assume the Firefox maintainer >> uses that mega-file to validate the download, then uses updpkgsums to >> update the current sha256sums rather than using copypasta on Firefox's >> SHA512SUMS file. > > no. you will never use less secure than upstream. the best must be used > to future-proof also. Yes, I will use less secure than upstream. What matters is that the Firefox maintainer has proven to himself that he isn't releasing maliciously-modified source code artifacts into the repositories. > copypasta? no one said to copy-paste anything without verifying first. And, you completely missed my point. >> Arch Linux doesn't even have a gnupg1 package, if you want to blame >> someone for the absolute inability to validate that key on Arch Linux >> (independent of makepkg) blame the GnuPG developers for dropping support >> of insecure and tremendously outdated keys. > > it does not matter. he will download it on his own to verify it, > and then he will add the sha512 message digest in the PKGBUILD file > to future-proof it. But "he" hasn't verified anything. That is the whole point, that ancient key format isn't secure and doesn't authenticate the message source. Also, there is no way Arch maintainers will install an AUR package just so they can read insecure keys to satisfy their curiosity about a package. >> Assuming they care about being securely identified on IRC. Maybe they do >> connect securely when they care about proving their identity for a >> specific conversation where it matters. >> >> I will grant you that for common sense alone you might as well connect >> securely whenever possible as it doesn't cost anything. But equally, it >> doesn't cost anything to *not* do so. > > "With great power comes great responsibility." > -Uncle Ben > > AL team members must be responsible with their power. > they must follow best security practices. All power corrupts. Absolute power corrupts absolutely. So if we are going with pop culture quotes, let's just be grateful the Arch maintainers aren't abusing their positions even more than they already are. -- Eli Schwartz signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
Le 10/12/2016 à 00:30, Leonid Isaev a écrit : > On Fri, Dec 09, 2016 at 03:15:34PM +0100, Bruno Pagani wrote: >> Le 08/12/2016 à 01:57, Leonid Isaev a écrit : >> >>> On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote: On 08/12/16 08:51, sivmu wrote: > Am 07.12.2016 um 10:49 schrieb Allan McRae: >>> ... >>> I advocate keeping md5sum as the default because it is broken. If I see >>> someone purely verifying their sources using md5sum in a PKGBUILD (and >>> not pgp signature), I know that they have done nothing to actually >>> verify the source themselves. >>> ... > That is a very dangerous assumtion. I know for a fact that many > maintainers used md5 for verification because it is the default. > There are/were maintainers that downloaded the source, verified the pgp > signature and generated the md5 checksum to include it in the PKGBUILD > (without the pgp signature) Idiots... so again using md5sums as the default saves me from people who don't know how to package. >>> Actually, this might not be so crazy. Sometimes you get a signed sha*sums >>> file >>> instead of signed source, so you don't include the key in validpgpkeys >>> array. >>> For example, when building Firefox, I have to manually verify the sig on >>> SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because >>> I'm >>> paranoid... I guess one can simply do makepkg -g, hmm. >>> >>> Hence the question, why have this flag at all? And should it be possible to >>> specify an external (signed) hash-file in PKGBUILD? >>> >>> Thx, >>> L. >> What is wrong with adding the sha*sum file and its signature in the >> source array and then use validpgpkeys? > And then what? Then makepkg would check the sigs on the sha*sum file, and you could either grep the sum from this file to use it in the PKGBUILD automatically (which is done in firefox-nightly-fr, probably not optimally now that I thought about it) or have a function to later verify the sum (don’t like that way, but it’s done in firefox-nightly for instance), or copy it by hand if it is for a stable package (which seems to be your use case). The goal here being that other people using the PKGBUILD get the same GPG verification. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Fri, Dec 09, 2016 at 03:15:34PM +0100, Bruno Pagani wrote: > Le 08/12/2016 à 01:57, Leonid Isaev a écrit : > > > On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote: > >> On 08/12/16 08:51, sivmu wrote: > >>> Am 07.12.2016 um 10:49 schrieb Allan McRae: > > ... > > I advocate keeping md5sum as the default because it is broken. If I see > > someone purely verifying their sources using md5sum in a PKGBUILD (and > > not pgp signature), I know that they have done nothing to actually > > verify the source themselves. > > ... > >>> That is a very dangerous assumtion. I know for a fact that many > >>> maintainers used md5 for verification because it is the default. > >>> There are/were maintainers that downloaded the source, verified the pgp > >>> signature and generated the md5 checksum to include it in the PKGBUILD > >>> (without the pgp signature) > >> Idiots... so again using md5sums as the default saves me from people > >> who don't know how to package. > > Actually, this might not be so crazy. Sometimes you get a signed sha*sums > > file > > instead of signed source, so you don't include the key in validpgpkeys > > array. > > For example, when building Firefox, I have to manually verify the sig on > > SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because > > I'm > > paranoid... I guess one can simply do makepkg -g, hmm. > > > > Hence the question, why have this flag at all? And should it be possible to > > specify an external (signed) hash-file in PKGBUILD? > > > > Thx, > > L. > > What is wrong with adding the sha*sum file and its signature in the > source array and then use validpgpkeys? And then what? -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 10/12/16 02:05, NicoHood wrote: > An official rule would be still better. So let us know what you (devs) > think about this finally. Been there, done that...
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/08/2016 03:14 PM, Bennett Piater wrote: >>> Is there any voting system that we have so that we can also >>> democratically vote for stronger hashes? >> >> The Arch developers decide this, not a democratically vote ;). > > Arch is not a democracy, that has been said many times. > That is true and also make sense in some cases. However we somehow need an official statement then, as all facts are given by now. Some TU votes might still help, however I am really glad that so many people raised up their word here. As an alternative if the main devs do not want to make it a general rule we could use the Trusted User Section on AUR to create a proposal about using strong hashes for community. We can then make it a community only rule or also "just" a guideline everyone can follow or not. Everyone who complies to this guideline can mark their package so and others will follow. An official rule would be still better. So let us know what you (devs) think about this finally. ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
Le 08/12/2016 à 01:57, Leonid Isaev a écrit : > On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote: >> On 08/12/16 08:51, sivmu wrote: >>> Am 07.12.2016 um 10:49 schrieb Allan McRae: > ... > I advocate keeping md5sum as the default because it is broken. If I see > someone purely verifying their sources using md5sum in a PKGBUILD (and > not pgp signature), I know that they have done nothing to actually > verify the source themselves. > ... >>> That is a very dangerous assumtion. I know for a fact that many >>> maintainers used md5 for verification because it is the default. >>> There are/were maintainers that downloaded the source, verified the pgp >>> signature and generated the md5 checksum to include it in the PKGBUILD >>> (without the pgp signature) >> Idiots... so again using md5sums as the default saves me from people >> who don't know how to package. > Actually, this might not be so crazy. Sometimes you get a signed sha*sums file > instead of signed source, so you don't include the key in validpgpkeys array. > For example, when building Firefox, I have to manually verify the sig on > SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because I'm > paranoid... I guess one can simply do makepkg -g, hmm. > > Hence the question, why have this flag at all? And should it be possible to > specify an external (signed) hash-file in PKGBUILD? > > Thx, > L. What is wrong with adding the sha*sum file and its signature in the source array and then use validpgpkeys? Bruno signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
Okay, first things first -- what happened to replying in-thread with a message-id linking together replies? Oh right, you are once again using disposable, temporary Mailinator email addresses (via their alternate domains). Admin note: Please, someone add everything here to the invalid email domains list, as this is getting annoying: https://gist.github.com/nocturnalgeek/1b8fa44283314544c487 On 12/08/2016 12:20 PM, fnodeuser wrote: > checksums and message digests are not the same thing.[1] > > checksums are not suitable for integrity verification, and the best > (meaning, at the time of writing and for the foreseeable future, most > secure), currently supported cryptographic hash function algorithm > (that is sha512 in AL's case), must be used to compute the message > digests of the files. > > message digests are one of the things that we can and must use for > security. not all upstreams have https enabled and not all of them > sign their files with gpg. Sure they're the same. It is the same underlying technology, used for the same purposes (and not just by Arch). > it was because of me that the 'Use gpg signatures and https sources' > task was added to the todo list.[2][3][4] Thanks, I guess. Although I cannot help but notice you were rather aggressive about it. Can't you raise these concerns in a slightly more polite manner? > these things must be checked by the users also, not only by the > package maintainers. i check everything, most of you check nothing. > you just do 'pacman -Syu'. Um, what? `pacman -Syu` does, in fact, check that every package is signed by a Developer or Trusted User whose key is in archlinux-keyring. I can hope for the day when the repo database will be signed as well (to avoid malicious mirror "downgrade"/vulnerability-freezing attacks), but in the meantime I am still pretty secure. Unless, of course, you are suggesting that I should have no faith in the honesty of the Arch Linux Devs/TUs. > let us start with firefox's PKGBUILD file for the first example. you > are using sha256mds instead of sha512mds. you can see at > https://ftp.mozilla.org/pub/firefox/releases/50.0.2/, that there are > 3 files, KEY, SHA512SUMS, and SHA512SUMS.asc. that is one example > where you are using a smaller digest size than upstream, that cannot > be verified with the signature. another example is nmap's PKGBUILD > file. you continued to use sha1mds instead of sha512mds.[5] sha256sums is plenty secure enough. So I assume the Firefox maintainer uses that mega-file to validate the download, then uses updpkgsums to update the current sha256sums rather than using copypasta on Firefox's SHA512SUMS file. Would it be nice to use the same checksums? Yes. Am I afraid I am running malicious Firefox packages? No. Open a bugreport. Or show us where you brought it to the attention of the maintainer. > in Gentoo they use 3 mds and in Debian they use 2 mds (for all > packages, regardless of what upstreams do or do not do (in Debian's > case they sign the files containing the mds)).[6][7] And in Arch Linux, unlike Gentoo, packages are binary and securely signed. Signing the sources yourself proves nothing, especially if you don't even have a mark of trust like being a TU/Dev -- so that is straight out for the AUR, which is where people other than the maintainer would benefit from *the maintainer* signing the sources. Debian does a lot of weird things, like hosting and patching the sources themselves, I am not surprised they sign the sources themselves. > there are a few package maintainers who insist on using and/or are > still using only a part of the commit or tag hash. the whole commit > or tag hash must be used, always. Pointers? Bugreports? > the refusal to future-proof.[8] i talked with the lsof upstream. he > told me that he has retired, that he is old, and that he might stop > maintaining it. it is unlikely that he will create a new keypair any > time soon and he might never do that. What? Creating a key is pretty easy. Arch Linux doesn't even have a gnupg1 package, if you want to blame someone for the absolute inability to validate that key on Arch Linux (independent of makepkg) blame the GnuPG developers for dropping support of insecure and tremendously outdated keys. The foundational premise of GnuPG here, seems to be that such keys offer very little security, the kind that isn't worth having. Why doesn't the lsof developer future-proof himself, with 5 minutes of effort? If he does so, we will be able to use the signatures! > another bad thing that many AL team members do, is connecting to irc > servers without using tls and certificate verification. Assuming they care about being securely identified on IRC. Maybe they do connect securely when they care about proving their identity for a specific conversation where it matters. I will grant you that for common sense alone you might as well connect securely whenever possible as it doesn't cost anything. But equally, it doesn't cos
Re: [arch-general] Stronger Hashes for PKGBUILDs
>> Is there any voting system that we have so that we can also >> democratically vote for stronger hashes? > > The Arch developers decide this, not a democratically vote ;). Arch is not a democracy, that has been said many times. -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Thu, 8 Dec 2016 14:52:20 +0100, NicoHood wrote: >Is there any voting system that we have so that we can also >democratically vote for stronger hashes? The Arch developers decide this, not a democratically vote ;).
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/08/2016 01:34 AM, Allan McRae wrote: > On 08/12/16 08:51, sivmu wrote: >> Am 07.12.2016 um 10:49 schrieb Allan McRae: ... I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. ... >> That is a very dangerous assumtion. I know for a fact that many >> maintainers used md5 for verification because it is the default. >> There are/were maintainers that downloaded the source, verified the pgp >> signature and generated the md5 checksum to include it in the PKGBUILD >> (without the pgp signature) > > Idiots... so again using md5sums as the default saves me from people > who don't know how to package. > > A > Calling those idiots is not the way to solve this problem. The fact is that if we use a (strong) hash and multiple people compare their hash against that, we can ensure that everyone downloads the same sources. Setting the default to sha512sums helps in more cases than using md5 as "bad karma" flag does. Did it ever help you that you saw someone using md5? Or wouldn't it be better to guide them into the right direction by a) using sha512sums as default and b) adding a warning when no https and gpg is used? I think we should at least implement those warnings, no matter what hash we use. Our main goal is to have every sources signed with gpg and downloaded by https. Is there any voting system that we have so that we can also democratically vote for stronger hashes? It seems to me that the majority (who spoke up on the list) is for stronger hashes. All technical facts have been said and we should come to a final agreement now. ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Thu, Dec 08, 2016 at 10:34:59AM +1000, Allan McRae wrote: > On 08/12/16 08:51, sivmu wrote: > > Am 07.12.2016 um 10:49 schrieb Allan McRae: > >> > ... > >> > I advocate keeping md5sum as the default because it is broken. If I see > >> > someone purely verifying their sources using md5sum in a PKGBUILD (and > >> > not pgp signature), I know that they have done nothing to actually > >> > verify the source themselves. > >> > ... > > That is a very dangerous assumtion. I know for a fact that many > > maintainers used md5 for verification because it is the default. > > There are/were maintainers that downloaded the source, verified the pgp > > signature and generated the md5 checksum to include it in the PKGBUILD > > (without the pgp signature) > > Idiots... so again using md5sums as the default saves me from people > who don't know how to package. Actually, this might not be so crazy. Sometimes you get a signed sha*sums file instead of signed source, so you don't include the key in validpgpkeys array. For example, when building Firefox, I have to manually verify the sig on SHA512SUMS and then paste the sha512sum into PKGBUILD. But this is because I'm paranoid... I guess one can simply do makepkg -g, hmm. Hence the question, why have this flag at all? And should it be possible to specify an external (signed) hash-file in PKGBUILD? Thx, L. -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 08/12/16 08:51, sivmu wrote: > Am 07.12.2016 um 10:49 schrieb Allan McRae: >> > ... >> > I advocate keeping md5sum as the default because it is broken. If I see >> > someone purely verifying their sources using md5sum in a PKGBUILD (and >> > not pgp signature), I know that they have done nothing to actually >> > verify the source themselves. >> > ... > That is a very dangerous assumtion. I know for a fact that many > maintainers used md5 for verification because it is the default. > There are/were maintainers that downloaded the source, verified the pgp > signature and generated the md5 checksum to include it in the PKGBUILD > (without the pgp signature) Idiots... so again using md5sums as the default saves me from people who don't know how to package. A
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Wed, 7 Dec 2016 11:44:11 +0100 Bennett Piater wrote: > Maybe giving a warning ("source authenticity was not verified due to > lack of GPG signature") would work? I find this a great idea. It's transparent, and this way people get frequently reminded about that security issue. Or like sivmu said: > A big fat warning about missing validation should automatically be > generated in any package that misses signatures or at least https source > downloads. Regards, Merlin -- Merlin Büge
Re: [arch-general] Stronger Hashes for PKGBUILDs
Am 07.12.2016 um 10:49 schrieb Allan McRae: > ... > I advocate keeping md5sum as the default because it is broken. If I see > someone purely verifying their sources using md5sum in a PKGBUILD (and > not pgp signature), I know that they have done nothing to actually > verify the source themselves. > ... That is a very dangerous assumtion. I know for a fact that many maintainers used md5 for verification because it is the default. There are/were maintainers that downloaded the source, verified the pgp signature and generated the md5 checksum to include it in the PKGBUILD (without the pgp signature) md5 is associated with security even though it is broken. People who do not know they can use a different checksum, will assume the arch build system is just that crappy and md5sum it the only available validation. What you associate with md5 is not relevant. Am 07.12.2016 um 11:09 schrieb Allan McRae: > On 07/12/16 19:58, Gregory Mullen wrote: >>> But we don't care about that... we just want to feel warm and fuzzy with >> a false sense of security. >> >> No one is suggesting sha*sum replace, and actual security/authentication >> check. Only that maybe it's not a good idea to use a system we all know is >> broken. >> > > If everyone knows it is broken, upstream will not be providing md5sums > to compare against and then and PKGBUILD maintainer that has verified > the source files using upstream provided hashes will not use md5sum. > Again, very dangerous assumtion > All we do by changing away from md5sum as the default is hiding the > large number of packages that do nothing to verify upstream source > integrity. > > In fact, I am making CRC the default. > I hope that is NOT sarcasm. No seriously thats what I had in mind from the start, making sure md5 is not taken as a security thing. Using a line like crc_checksum_NOTFORSECUREVERIFICATION!!! is an even better idea. If you want to know if the package source is verified, why not use the existance of https or pgp signatures in the build file? Do you think any default will keep maintainers from generating sha512 checksums without verifying the sources? A big fat warning about missing validation should automatically be generated in any package that misses signatures or at least https source downloads. And while we are at it I would like to point out that git downloads are used as verification as well and I'm not sure what a crypto expert would say about that. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Wed, Dec 07, 2016 at 01:58:16AM -0800, Gregory Mullen wrote: > > I advocate keeping md5sum as the default because it is broken. If I see > someone purely verifying their sources using md5sum in a PKGBUILD (and > not pgp signature), I know that they have done nothing to actually > verify the source themselves. > > I advocate making the default house construction straw... Said the wolf to > the three little pigs. > > Advocating for MD5 as a "this package is insecure" warning flag makes NO > sense at all. Especially when if the package is secure (because the > maintainer verified the PGP sig, and then changed to shaXXX) you still no > nothing new. But don't say; MD5 is good because I know it's broken, so I > know the maintainer didn't do their job? > > Either validate the PGP keys, or don't. But don't suggest keeping a broken > system because... why again? So you can learn nothing? I think you misunderstood Allan. What he says is that by default makepkg provides only a protection against broken http links at best. If a maintainer wants security, he must take care of it explicitly. I don't see why this is a bad idea... Cheers, L. -- Leonid Isaev
Re: [arch-general] Stronger Hashes for PKGBUILDs
> You are partly right. For a checksum CRC would be best. Fast and > simple, as its meant as checksum, not as a hash. You misunderstand something. Every checksum is also a hash (a mapping to another domain), and cryptographic hash functions always produce checksums. > So possibly we should get our point of view into the direction that > those hashes are not checksums, but rather integrity checks. This is wrong. Checksum checks *are* integrity checks. That's what they are. I think you should read up on some terminology because either you misunderstand something very basic, or you confuse others by using words differently from everyone else. Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/07/2016 10:49 AM, Allan McRae wrote: > > I advocate keeping md5sum as the default because it is broken. If I see > someone purely verifying their sources using md5sum in a PKGBUILD (and > not pgp signature), I know that they have done nothing to actually > verify the source themselves. > > If sha2sums become default, I now know nothing. Did the maintainer of > the PKGBUILD get that checksum from a securely distributed source from > upstream? Had the source already been compromised upstream before the > PKGBUILD was made? Now I am securely verifying the unknown. > > But we don't care about that... we just want to feel warm and fuzzy > with a false sense of security. > > A > You are partly right. For a checksum CRC would be best. Fast and simple, as its meant as checksum, not as a hash. However if we drop the other hashes we loose the whole integrity for those cases that people already explained[1]. We all aggree that md5 as hash is broken. So possibly we should get our point of view into the direction that those hashes are not checksums, but rather integrity checks. Once again: This does not help in the very first place of downloading. But it helps on AUR where multiple users download the files and would get errors on wrong hashes (if the source got modified later or if a MITM occured). In those cases users can compare against the hash of others (maintainer) and at least verify that their source was the same (integrity). Also if you say that you can notice the people who do not care about security by using md5 you can pass the buck to this guy. But this does not solve anything. And on top there are still a LOT package on the official repositories that still use md5/sha1. And I really do not understand why, because those should be aware of the problem. We should not make the problem worse by using CRC. We should carefully understand when the integrity check helps. If if its not meant for integrity, the wiki is wrong, as it calls it integrity not checksum. There is no real valid argument about using lower security standards. Even if people might misunderstand the meaning of the hashes, they do not understand security at all. And those can still be helped with a good explanation of those checks on the wiki with a link to the GPG templates (see below). [1] https://lists.archlinux.org/pipermail/arch-general/2016-December/042737.html On 12/07/2016 11:17 AM, Gregory Mullen wrote: > If the argument left is, I don't want (better checksum) because it's > shouldn't be thought of as a security check, and I want a security check. > > Why can't the requirement be PGP sig's are now required, and we drop the > checksum completely? > That is also what I suggest. If we only move GPG signed Packages to community, the whole situation will improve. A lot more upstream projects will then possibly try to use GPG if they want to make it into our (and possibly also other) distributions. What we need here is more action from the maintainer side. I've linked my templates for contacting upstream about using GPG. With those it would be really easy for them to understand what we need, why and how to accomplish it. We already agreed that we need to use GPG whenever possible, but we should also try to do our best to get upstream to do so. It is really simple. ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 07-12-16 11:44, Bennett Piater wrote: On 12/07/2016 11:17 AM, Gregory Mullen wrote: If the argument left is, I don't want (better checksum) because it's shouldn't be thought of as a security check, and I want a security check. Why can't the requirement be PGP sig's are now required, and we drop the checksum completely? Won't work because many upstreams don't provide signatures. Maybe giving a warning ("source authenticity was not verified due to lack of GPG signature") would work? I vote to rename all *sums fields in PKGBUILD to : this_is_just_a_checksum_and_does_no_authentication_at_all-xyzsums Would it be possible to focus all this energy on ideas to make things safer instead of wrongly treating checksums as a security feature ? LW
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/07/2016 11:17 AM, Gregory Mullen wrote: > If the argument left is, I don't want (better checksum) because it's > shouldn't be thought of as a security check, and I want a security check. > > Why can't the requirement be PGP sig's are now required, and we drop the > checksum completely? Won't work because many upstreams don't provide signatures. Maybe giving a warning ("source authenticity was not verified due to lack of GPG signature") would work? -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
Off-topic for amusement only: PGP checks are not necessarily more secure. Some foolish comments are already deleted at https://aur.archlinux.org/packages/freetype2-infinality/?comments=all Somebody recommended to e.g. use "--skippgpcheck", another reply asked from where I got the information what keyserver to use. Regards, Ralf
Re: [arch-general] Stronger Hashes for PKGBUILDs
If the argument left is, I don't want (better checksum) because it's shouldn't be thought of as a security check, and I want a security check. Why can't the requirement be PGP sig's are now required, and we drop the checksum completely? On Wed, Dec 7, 2016 at 2:14 AM, Bennett Piater wrote: > > In fact, I am making CRC the default. > > I assume this to be sarcasm. > In any case, this may not be a good idea because the younglings will > have never heard about it and don't know how insecure it is ;) > > Cheers, > Bennett > > -- > GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808 > >
Re: [arch-general] Stronger Hashes for PKGBUILDs
> In fact, I am making CRC the default. I assume this to be sarcasm. In any case, this may not be a good idea because the younglings will have never heard about it and don't know how insecure it is ;) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 07/12/16 19:58, Gregory Mullen wrote: >> But we don't care about that... we just want to feel warm and fuzzy with > a false sense of security. > > No one is suggesting sha*sum replace, and actual security/authentication > check. Only that maybe it's not a good idea to use a system we all know is > broken. > If everyone knows it is broken, upstream will not be providing md5sums to compare against and then and PKGBUILD maintainer that has verified the source files using upstream provided hashes will not use md5sum. All we do by changing away from md5sum as the default is hiding the large number of packages that do nothing to verify upstream source integrity. In fact, I am making CRC the default. A
Re: [arch-general] Stronger Hashes for PKGBUILDs
> I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. I advocate making the default house construction straw... Said the wolf to the three little pigs. Advocating for MD5 as a "this package is insecure" warning flag makes NO sense at all. Especially when if the package is secure (because the maintainer verified the PGP sig, and then changed to shaXXX) you still no nothing new. But don't say; MD5 is good because I know it's broken, so I know the maintainer didn't do their job? Either validate the PGP keys, or don't. But don't suggest keeping a broken system because... why again? So you can learn nothing? > But we don't care about that... we just want to feel warm and fuzzy with a false sense of security. No one is suggesting sha*sum replace, and actual security/authentication check. Only that maybe it's not a good idea to use a system we all know is broken. On Wed, Dec 7, 2016 at 1:49 AM, Allan McRae wrote: > On 07/12/16 19:35, Gregory Mullen wrote: > > Grayhatter here, developer of Tox -- The security centered TAV client. No > > matter what the reason is, NO ONE should be using MD5. We can argue about > > what hash we want to use, but literally nothing, is better than using > MD5. > > I don't mean MD5 is better than everything else, I mean NOT using a hash, > > is better than using MD5. > > Ignoring "slight" exaggerations... > > > The argument that an insecure hash is fine because it doesn't need to be > > secure, and that PGP is a better replacement; Is a plainly BAD argument. > > The issue at hand is not, what should we use to verify the authenticity > of > > the packages. The question is, is MD5 an acceptable hashing algorithm? We > > all know it's not. If given the choice, NO ONE who knows about the > SERIOUS > > issues with MD5 would think it's a reasonable suggestion. > > > > Switching to sha256/512 isn't a hard switch `sha{256,512}sum` is in > > coreutils (a member of base no less). > > > > To recap... we have a lot of good reasons to drop MD5 like the broken > algo > > it is. No applicable reasons why need to keep it. So... why haven't we > > replaced it yet? > > I advocate keeping md5sum as the default because it is broken. If I see > someone purely verifying their sources using md5sum in a PKGBUILD (and > not pgp signature), I know that they have done nothing to actually > verify the source themselves. > > If sha2sums become default, I now know nothing. Did the maintainer of > the PKGBUILD get that checksum from a securely distributed source from > upstream? Had the source already been compromised upstream before the > PKGBUILD was made? Now I am securely verifying the unknown. > > But we don't care about that... we just want to feel warm and fuzzy > with a false sense of security. > > A >
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 07/12/16 19:35, Gregory Mullen wrote: > Grayhatter here, developer of Tox -- The security centered TAV client. No > matter what the reason is, NO ONE should be using MD5. We can argue about > what hash we want to use, but literally nothing, is better than using MD5. > I don't mean MD5 is better than everything else, I mean NOT using a hash, > is better than using MD5. Ignoring "slight" exaggerations... > The argument that an insecure hash is fine because it doesn't need to be > secure, and that PGP is a better replacement; Is a plainly BAD argument. > The issue at hand is not, what should we use to verify the authenticity of > the packages. The question is, is MD5 an acceptable hashing algorithm? We > all know it's not. If given the choice, NO ONE who knows about the SERIOUS > issues with MD5 would think it's a reasonable suggestion. > > Switching to sha256/512 isn't a hard switch `sha{256,512}sum` is in > coreutils (a member of base no less). > > To recap... we have a lot of good reasons to drop MD5 like the broken algo > it is. No applicable reasons why need to keep it. So... why haven't we > replaced it yet? I advocate keeping md5sum as the default because it is broken. If I see someone purely verifying their sources using md5sum in a PKGBUILD (and not pgp signature), I know that they have done nothing to actually verify the source themselves. If sha2sums become default, I now know nothing. Did the maintainer of the PKGBUILD get that checksum from a securely distributed source from upstream? Had the source already been compromised upstream before the PKGBUILD was made? Now I am securely verifying the unknown. But we don't care about that... we just want to feel warm and fuzzy with a false sense of security. A
Re: [arch-general] Stronger Hashes for PKGBUILDs
Grayhatter here, developer of Tox -- The security centered TAV client. No matter what the reason is, NO ONE should be using MD5. We can argue about what hash we want to use, but literally nothing, is better than using MD5. I don't mean MD5 is better than everything else, I mean NOT using a hash, is better than using MD5. The argument that an insecure hash is fine because it doesn't need to be secure, and that PGP is a better replacement; Is a plainly BAD argument. The issue at hand is not, what should we use to verify the authenticity of the packages. The question is, is MD5 an acceptable hashing algorithm? We all know it's not. If given the choice, NO ONE who knows about the SERIOUS issues with MD5 would think it's a reasonable suggestion. Switching to sha256/512 isn't a hard switch `sha{256,512}sum` is in coreutils (a member of base no less). To recap... we have a lot of good reasons to drop MD5 like the broken algo it is. No applicable reasons why need to keep it. So... why haven't we replaced it yet? On Tue, Dec 6, 2016 at 7:37 PM, David C. Rankin < drankina...@suddenlinkmail.com> wrote: > On 12/03/2016 10:37 PM, Maxwell Anselm via arch-general wrote: > >> You mean the source files that you downloaded and then hashed... > >> > > Yes. If the source files are being modified via a MITM attack (which is > > trivial if the host uses HTTP) the checksum is still useful. > > This sounds a lot like a "solution in search of a problem to fix" and > blindly > applying any "fix" where it is proveably meaningless really causes > credibility > (not to mention the Arch KISS philosophy) to take a beating. > > I'm all for validation and stronger hashes, but applying them in a > circumstance where there is no way to validate against any original -- is > just > bat-shit crazy. > > -- > David C. Rankin, J.D.,P.E. >
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/03/2016 10:37 PM, Maxwell Anselm via arch-general wrote: >> You mean the source files that you downloaded and then hashed... >> > Yes. If the source files are being modified via a MITM attack (which is > trivial if the host uses HTTP) the checksum is still useful. This sounds a lot like a "solution in search of a problem to fix" and blindly applying any "fix" where it is proveably meaningless really causes credibility (not to mention the Arch KISS philosophy) to take a beating. I'm all for validation and stronger hashes, but applying them in a circumstance where there is no way to validate against any original -- is just bat-shit crazy. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/05/2016 11:45 PM, Eli Schwartz via arch-general wrote: > On 12/05/2016 05:25 PM, sivmu wrote: >> A LOT of packages do not use pgp validation even though upstream >> provides signatures. That is the real issue here. >> >> Let me say this again: everyone who is responsible for arch packages >> needs to be clearly advised to use all available methods to effectively >> verify upstream source files. >> >> Using a strong hash by default won't do that. > > AUR packages, or repo packages? There was a todo list[1] for the repos. > > For anything in the AUR you should definitely drop a comment on their > page. And change the wiki guidelines on packaging standards to mention this. > Yes we really should change the wiki. I once already did, but it got reverted. The argument about false security is somehow valid. People should not think that is replaces a GPG signature. However those people do not care at all, and if they'd use sha512 it can only have positive effects. It does not only (but especially) apply to AUR. But i also had to rebuild some official packages (because of several issues or modifications). And strong hashes would ensure I get the same sources as the maintainer used. So the real solution is to set strong hashes as default to help those who just dont know what is more important. But we also need to explain in which situations and why they are important (wiki). And furthermore people should be encouraged to ask upstream to sign their sources with gpg. I did this with a lot of sources already and I also try to explain it as simple as possible for them. The more people start using GPG, the more those who dont will understand the importance. And this would also solve the hash issue. I got really positive feedback so far and also questions about GPG. People do want to secure their stuff, but they dont know how or dont know how easy it is. Going further I personally will not move any package to [community] unless it provides GPG signatures (excluding arduino as I've already uploaded parts of it). Here is a tutorial how to setup gpg real quick and also a template to ask upstream for GPG signatures. Any contributions appreciated. https://github.com/NicoHood/NicoHood.github.io/wiki/How-to-sign-sources-with-GPG-in-under-5-minutes https://github.com/NicoHood/NicoHood.github.io/wiki/GPG-signatures-for-source-validation ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
Am 05.12.2016 um 23:45 schrieb Eli Schwartz via arch-general: > On 12/05/2016 05:25 PM, sivmu wrote: >> A LOT of packages do not use pgp validation even though upstream >> provides signatures. That is the real issue here. >> >> Let me say this again: everyone who is responsible for arch packages >> needs to be clearly advised to use all available methods to effectively >> verify upstream source files. >> >> Using a strong hash by default won't do that. > > AUR packages, or repo packages? There was a todo list[1] for the repos. > > For anything in the AUR you should definitely drop a comment on their > page. And change the wiki guidelines on packaging standards to mention this. > Wow thanks for the link, I did not kow that yet. That looks awesome. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/05/2016 05:25 PM, sivmu wrote: > A LOT of packages do not use pgp validation even though upstream > provides signatures. That is the real issue here. > > Let me say this again: everyone who is responsible for arch packages > needs to be clearly advised to use all available methods to effectively > verify upstream source files. > > Using a strong hash by default won't do that. AUR packages, or repo packages? There was a todo list[1] for the repos. For anything in the AUR you should definitely drop a comment on their page. And change the wiki guidelines on packaging standards to mention this. -- Eli Schwartz [1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/
Re: [arch-general] Stronger Hashes for PKGBUILDs
Am 05.12.2016 um 21:50 schrieb Eli Schwartz via arch-general: > On 12/05/2016 02:56 PM, sivmu wrote: >> Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general: You mean the source files that you downloaded and then hashed... >>> >>> Yes. If the source files are being modified via a MITM attack (which is >>> trivial if the host uses HTTP) the checksum is still useful. >> >> The checksum that was created by zou after downloading the compromised >> source file. >> >> I don't see how that is useful. The checksum will always be correct and >> validate nothing >> > > Possibilities > > 1) MITM attack between end-user and internet. PKGBUILD is downloaded > over HTTPS, but source files are downloaded over HTTP. MITM attack > cannot manipulate the PKGBUILD, but can fake the sources. > > AUR maintainer was probably not under the same MITM. ;) Why apply this only to AUR? The same is true for the regular repositories, but in that case you only need to MITM the maintainer and the checksums will not help. But yes for AUR this can help. > > 2) Source website hacked. AUR maintainer blindly generates checksums > from the compromised source, nothing else matters because everyone is > screwed. > Except if pgp signatures are provided by upstream und used in the PKGBUILD > 3) Source website hacked, after the AUR maintainer generates checksums > from the original uncompromised source. > This use case is valid. > ... > > In cases #1 & #3 (and #3 is only by accident) stronger checksums *will* > help. > Those are also the cases where it is more likely the maintainer is > security-conscious and checks the sources before generating the > manually-upgraded-to-sha256-or-higher checksums. > > ... > > Context is everything. I am sure many people who read this thread are > not aware of the following forum thread in which the matter was > extensively discussed: https://bbs.archlinux.org/viewtopic.php?id=217588 > > Allan has already declared that he will not change the default > makepkg.conf, on the grounds that #2 is the most likely scenario for > people getting malicious packages. > He also wants everyone to know that updpkgsums and makepkg are perfectly > okay with maintainers changing the defaults, people who don't know there > are defaults to change are probably not your best bet security-wise, and > the only real security is either PGP or strong checksums posted by > upstream on a second website. > Also, that changing the defaults will encourage a false sense of > security when people think that checksums have any validity in > authentication. > > Personally, I want the defaults changed because of #1 & #3, but it > doesn't seem that will happen *as a matter of principle* so I guess > everyone can continue bikeshedding here. Or in arch-dev-public. (Though > having a TU take up the fight is indeed somewhat more useful than random > users, so who knows?) > One valid reason to change the default checksum in general to a stronger algo, would be to prevent maintainer from using md5 as a security checksum. It is currently used for error detection during download. But using a strong hash is only really useful when there is a way to verify it. e.g. by pgp signatures or at least checksums on a https site. So if there is a way to verify upstream packages, using md5 inside PKGBUILD is bad. If there is no way to verify the upstream packages, using a stronger hash will provide a false sense of security. And thats what many seem to use it for. Thats partly why Allan won't change the default (if I understood him correctly) I my opinion, the way to solve this is to change the default md5 checksum to a different weaker one, preferably alias it to make sure it is understood as a error detection algorithmus. That way maintainers will understand that there is no verification of upstream packages by default and that they need to take care of that themselfs. The second change needed would be to strongly encourage maintainers to use pgp validation if available or to use strong checksum after getting packages over https. A LOT of packages do not use pgp validation even though upstream provides signatures. That is the real issue here. Let me say this again: everyone who is responsible for arch packages needs to be clearly advised to use all available methods to effectively verify upstream source files. Using a strong hash by default won't do that. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
> > Allan has already declared that he will not change the default > makepkg.conf, on the grounds that #2 is the most likely scenario for > people getting malicious packages. > He also wants everyone to know that updpkgsums and makepkg are perfectly > okay with maintainers changing the defaults, people who don't know there > are defaults to change are probably not your best bet security-wise, and > the only real security is either PGP or strong checksums posted by > upstream on a second website. > Also, that changing the defaults will encourage a false sense of > security when people think that checksums have any validity in > authentication. > The only change I can think of would be some way for the PKGBUILD to distinguish between "official" checksums (to defend against all cases) and "unofficial" checksums (to defend against #1 and #3). But that's a matter for arch-dev-public.
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/05/2016 02:56 PM, sivmu wrote: > Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general: >>> You mean the source files that you downloaded and then hashed... >> >> Yes. If the source files are being modified via a MITM attack (which is >> trivial if the host uses HTTP) the checksum is still useful. > > The checksum that was created by zou after downloading the compromised > source file. > > I don't see how that is useful. The checksum will always be correct and > validate nothing > Possibilities 1) MITM attack between end-user and internet. PKGBUILD is downloaded over HTTPS, but source files are downloaded over HTTP. MITM attack cannot manipulate the PKGBUILD, but can fake the sources. AUR maintainer was probably not under the same MITM. ;) 2) Source website hacked. AUR maintainer blindly generates checksums from the compromised source, nothing else matters because everyone is screwed. 3) Source website hacked, after the AUR maintainer generates checksums from the original uncompromised source. ... In cases #1 & #3 (and #3 is only by accident) stronger checksums *will* help. Those are also the cases where it is more likely the maintainer is security-conscious and checks the sources before generating the manually-upgraded-to-sha256-or-higher checksums. ... Context is everything. I am sure many people who read this thread are not aware of the following forum thread in which the matter was extensively discussed: https://bbs.archlinux.org/viewtopic.php?id=217588 Allan has already declared that he will not change the default makepkg.conf, on the grounds that #2 is the most likely scenario for people getting malicious packages. He also wants everyone to know that updpkgsums and makepkg are perfectly okay with maintainers changing the defaults, people who don't know there are defaults to change are probably not your best bet security-wise, and the only real security is either PGP or strong checksums posted by upstream on a second website. Also, that changing the defaults will encourage a false sense of security when people think that checksums have any validity in authentication. Personally, I want the defaults changed because of #1 & #3, but it doesn't seem that will happen *as a matter of principle* so I guess everyone can continue bikeshedding here. Or in arch-dev-public. (Though having a TU take up the fight is indeed somewhat more useful than random users, so who knows?) -- Eli Schwartz
Re: [arch-general] Stronger Hashes for PKGBUILDs
Am 04.12.2016 um 05:37 schrieb Maxwell Anselm via arch-general: >> >> You mean the source files that you downloaded and then hashed... >> > > Yes. If the source files are being modified via a MITM attack (which is > trivial if the host uses HTTP) the checksum is still useful. > The checksum that was created by zou after downloading the compromised source file. I don't see how that is useful. The checksum will always be correct and validate nothing signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
> > So what do you guys think if we make our implicit standards available > somewhere on the wiki. This would make it more transparent on how we > build stuff, how TUs should package and give a guideline for AUR > maintainers, as they might not know about some details like this. > The best way to get that ball rolling is to just add it somewhere. The maintenance team usually weighs in pretty quickly on the talk pages. Possible pages for the info could be: https://wiki.archlinux.org/index.php/Arch_packaging_standards or https://wiki.archlinux.org/index.php/Arch_User_Repository
Re: [arch-general] Stronger Hashes for PKGBUILDs
On 12/03/2016 07:21 PM, sivmu wrote: > > > Am 03.12.2016 um 06:27 schrieb fnodeuser: > >> >> if an upstream does not sign the files, does not have https enabled, and/or >> refuses to take security and privacy seriously, sha512 must be used in the >> PKGBUILD files. > > But using and hash value without the possibility to verify the hashed > files, adds no security. It provides a false sense of security instead. > > I agree that we should use a strong hash by default where it makes > sense. But in the absense ob effective validation of upstream packages, > this is meaningless. > It adds (possible) security for those who want to rebuild the package at a later time or modify the PKGBUILD. It ensures they get the exact same sources as the original publisher. This comes especially into place if you live inside a country where you do not have much freedom online. I also like the suggestion to also sign the ISO files with sha512sums. It would not cause any trouble to add one more hash and a lot more people will be happy. Great idea! I also got a request from AUR: https://aur.archlinux.org/packages/snap-sync/ Those suggestions should be written down somewhere. I agree with this, as I also did a lot of things wrong and the PKGBUILD police (anthraxx) corrected those for me. I think a simple checklist with examples would be nice. This could contain: * Use https whenever possible * Use GPG whenever possible * Ask upstream if they do not use https and gpg yet (with some templates I made) * Use strong hashes * Add a note about the simple devtools chroot build and updpkgsums function * Use unique sources (if you are building in the same source directory) * Mask all variables with quotes * Use .xz sources wherever possible (to speed up downloads on instable/slow connections) * Do not delete users on uninstall * Use an underscore for user variables * https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html So what do you guys think if we make our implicit standards available somewhere on the wiki. This would make it more transparent on how we build stuff, how TUs should package and give a guideline for AUR maintainers, as they might not know about some details like this. ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
> > You mean the source files that you downloaded and then hashed... > Yes. If the source files are being modified via a MITM attack (which is trivial if the host uses HTTP) the checksum is still useful.
Re: [arch-general] Stronger Hashes for PKGBUILDs
On Sat, Dec 3, 2016 at 6:27 AM, fnodeuser wrote: > https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html I would suggest considering TUF - The Update Framework or stealing their signing scheme which withstands all kinds of attack scenarios.
Re: [arch-general] Stronger Hashes for PKGBUILDs
Am 03.12.2016 um 20:07 schrieb Maxwell Anselm via arch-general: >> >> I agree that we should use a strong hash by default where it makes >> sense. But in the absense ob effective validation of upstream packages, >> this is meaningless. >> > > It would at least indicate that the source file has been tampered with in > some way. Even though there would be no way to know the "correct" checksum. > You mean the source files that you downloaded and then hashed... signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
> > I agree that we should use a strong hash by default where it makes > sense. But in the absense ob effective validation of upstream packages, > this is meaningless. > It would at least indicate that the source file has been tampered with in some way. Even though there would be no way to know the "correct" checksum.
Re: [arch-general] Stronger Hashes for PKGBUILDs
Am 03.12.2016 um 06:27 schrieb fnodeuser: > > if an upstream does not sign the files, does not have https enabled, and/or > refuses to take security and privacy seriously, sha512 must be used in the > PKGBUILD files. But using and hash value without the possibility to verify the hashed files, adds no security. It provides a false sense of security instead. I agree that we should use a strong hash by default where it makes sense. But in the absense ob effective validation of upstream packages, this is meaningless. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Stronger Hashes for PKGBUILDs
> if an upstream does not sign the files, does not have https enabled, and/or > refuses to take security and privacy seriously, sha512 must be used in the > PKGBUILD files. Then 1) you could argue our using SHA512 is meaningless, but 2) it doesn't matter; we should still be doing the Right™ thing. -Chris Tonkinson signature.asc Description: OpenPGP digital signature