Re: [arch-general] Stronger Hashes for PKGBUILDs

[Leonid Isaev via arch-general]

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

[Eli Schwartz via arch-general]

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

[Leonid Isaev via arch-general]

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

[Ralph Corderoy]

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

[Eli Schwartz via arch-general]

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

[Leonid Isaev via arch-general]

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

[Neven Sajko via arch-general]

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

[Neven Sajko via arch-general]

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

[Carsten Mattner via arch-general]

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

[Eli Schwartz via arch-general]

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

[Ralf Mardorf]

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

[Leonid Isaev via arch-general]

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

[NicoHood]

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

[Guus Snijders via arch-general]

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

[Leonid Isaev via arch-general]

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

[David C. Rankin]

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

[Neven Sajko via arch-general]

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

[Leonid Isaev via arch-general]

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

[Eli Schwartz via arch-general]

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

[Leonid Isaev via arch-general]

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

[Eli Schwartz via arch-general]

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=1

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Leonid Isaev via arch-general]

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

[Leonid Isaev via arch-general]

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

[Leonid Isaev via arch-general]

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
   

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Jürgen Hötzel]

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

[Eli Schwartz via arch-general]

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

[Leonid Isaev]

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

[Florian Pritz via arch-general]

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

[NicoHood]

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

[Allan McRae]

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

[NicoHood]

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

[Diego Viola via arch-general]

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

[Allan McRae]

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

[NicoHood]

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

[Allan McRae]

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

[Levente Polyak]

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 

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Eli Schwartz via arch-general]

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

[arch-general] Stronger Hashes for PKGBUILDs

[fnodeuser]

hello eli,

you have misread and misunderstood a few things.

reread carefully all the messages about the subject,
and check the links in my second email.

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.

>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.

>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.

copypasta? no one said to copy-paste anything without verifying first.

>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.

>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.

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Bruno Pagani]

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

[Leonid Isaev]

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

[Allan McRae]

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

[NicoHood]

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

[Bruno Pagani]

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

[Eli Schwartz via arch-general]

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 

[arch-general] Stronger Hashes for PKGBUILDs

[fnodeuser]

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.

it was because of me that the 'Use gpg signatures and https sources' task was 
added to the todo list.[2][3][4]

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'.

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]

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]

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.

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.

another bad thing that many AL team members do, is connecting to irc servers 
without using tls and certificate verification.

that is all for now.

_
[1] https://en.wikipedia.org/wiki/Checksum, 
https://en.wikipedia.org/wiki/Cryptographic_hash_function
[2] https://bugs.archlinux.org/task/51579
[3] 
https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028416.html
[4] https://bugs.archlinux.org/index.php?opened=23845[]=, 
https://bugs.archlinux.org/index.php?opened=23412[]=, and
https://bugs.archlinux.org/index.php?opened=23101[]=
[5] https://nmap.org/dist/sigs/nmap-7.31.tar.bz2.digest.txt
[6] https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/firefox/Manifest
[7] https://ftp.acc.umu.se/debian/pool/main/f/firefox/firefox_50.0.2-1.dsc
[8] https://bugs.archlinux.org/task/50482

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Bennett Piater]

>> 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

[Ralf Mardorf]

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

[NicoHood]

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

[Leonid Isaev]

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

[Allan McRae]

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

[Merlin Büge]

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

[sivmu]

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

[Leonid Isaev]

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

[Bennett Piater]

> 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

[NicoHood]

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

[LoneVVolf]

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

[Bennett Piater]

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

[Ralf Mardorf]

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

[Gregory Mullen]

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

[Bennett Piater]

> 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

[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.

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

[Gregory Mullen]

> 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

[Allan McRae]

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

[Gregory Mullen]

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

[David C. Rankin]

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

[NicoHood]

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

[sivmu]

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

[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.

-- 
Eli Schwartz

[1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

Re: [arch-general] Stronger Hashes for PKGBUILDs

[sivmu]

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

[Maxwell Anselm via arch-general]

>
> 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

[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. ;)

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

[sivmu]

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

[Maxwell Anselm via arch-general]

>
> 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

[NicoHood]

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

[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.

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Carsten Mattner via arch-general]

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

[sivmu]

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

[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.

Re: [arch-general] Stronger Hashes for PKGBUILDs

[sivmu]

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

[arch-general] Stronger Hashes for PKGBUILDs

[fnodeuser]

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.