Re: [arch-general] Thunderbird 78

[NicoHood]

Thunderbird 78 is in the repos for quite some time now. Can anyone
please explain me what is the best way to use GPG now for email encryption?

I read that Archlinux aims to use the system wide gpg keyring instead of
thunderbirds builtin store. Is that still the case and is that
implemented yet? Thunderbird asks me to migrate my keys, and I am not
sure, if I should not wait a few more days. Having the private key in
multiple places is really not the best idea in my opinion.

Depending on the current state we could also add a news on the archlinux
website or at least update the wiki:
https://wiki.archlinux.org/index.php/Thunderbird/Enigmail

Cheers
Nico

Re: [arch-general] Package signature error after updated GPG key

[NicoHood]

On 7/8/20 9:14 PM, Filipe Laíns via arch-general wrote:
> On Wed, 2020-07-08 at 21:08 +0200, NicoHood wrote:
>> Hey guys,
>> i have recently received the attached email from a user. He cannot
>> install a package from me due to a GPG error. I have recently updated my
>> key and it should have been added to the new keyring. I don't know a
>> better solution, who can help us?
>>
>> Cheers,
>> Nico
> 
> IIRC GPG uses the latest subkey by default, if you crated a new one it
> would be used, I assume this is what happened. If you haven't already
> revoked the older subkey(s), you should be able set GPGKEY in
> makepkg.conf and use it instead.
> 
> Cheers,
> Filipe Laíns
> 

I am not sure if I understood correct. I've simply refreshed the gpg key
(and the subkey) which was included into the new keyring. The package
that causes trouble is older than that change. Since makepkg refers to
package building, I think this does not help here. I expect that I do
not need to rebuild all packages just because the GPG key was renewed.

Is it more clear now?



signature.asc
Description: OpenPGP digital signature

[arch-general] Package signature error after updated GPG key

[NicoHood]

Hey guys,
i have recently received the attached email from a user. He cannot
install a package from me due to a GPG error. I have recently updated my
key and it should have been added to the new keyring. I don't know a
better solution, who can help us?

Cheers,
Nico

On 7/8/20 12:10 AM, cock.li wrote:
> Hi, sorry to bother you, I think that the signature on the snap-pac
> packet is expired or something similar, I'm getting this pacman error:
> 
> error: snap-pac: signature from "NicoHood " is unknown
> trust
> :: File /var/cache/pacman/pkg/snap-pac-2.3.1-1-any.pkg.tar.xz is
> corrupted (invalid or corrupted package (PGP signature)).
> 
> since, the keys are updated (I've tried updating them with a healthy
> "sudo pacman-key --refresh-keys", but nothing) i think that the key with
> wich the packet was signed expired and was changed in the meantime,
> especially since it's more than a year that there are no updates on the
> packet (since there are no commits on the source)
> 
> 
> I do need the packet for snap-pac-grub, please let me now as soon as you
> can
> 
> 
> regards
> 
> AmanuenseDelDiavolo
> 



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Orphaning some packages

[NicoHood]

Thanks you two for adopting the packages!

On 8/27/19 11:18 AM, David Runge wrote:
> On 2019-08-27 09:39:11 (+0200), NicoHood wrote:
>> I maintain a few packages that I do not use anymore myself.
>> to orphan those, as I currently do not have time to test them,
>> especially on major version upgrades. I want to keep the quality of our
>> packages and hope that somebody else can take over the following
>> packages. Otherwise I will move them to the AUR.
> arch-dev-public would be more suited for this request.
> 
>> * python-gitdb
>> * python-gitpython
>> * python-gnupg
>> * python-smmap
>> * python-utils
>> * python-progressbar
> I can do these.
> 
> btw: python-progressbar is a dependency of subdownloader and therefore
> moving python-utils or python-progressbar to the AUR is not an option.
> 
> Best,
> David
> 



signature.asc
Description: OpenPGP digital signature

[arch-general] Orphaning some packages

[NicoHood]

Hey guys!
I maintain a few packages that I do not use anymore myself. I would like
to orphan those, as I currently do not have time to test them,
especially on major version upgrades. I want to keep the quality of our
packages and hope that somebody else can take over the following
packages. Otherwise I will move them to the AUR.

* python-gitdb
* python-gitpython
* python-gnupg
* python-pyusb
* python-smmap
* python-utils
* python-progressbar

Cheers
Nico



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] AUR: Failing to install gnupod-git (no perl-date-parse)

[NicoHood]

On 9/7/18 2:08 PM, Jeanette C. via arch-general wrote:
> Hey hey,
> I just tried to install gnupod-git from AUR and there is one unmet
> dependency not found by either pacman or through AUR: perl-date-parse .
> 
> Short of building an AUR myself, is there something I could do?
> 
> Best wishes,
> 
> Jeanette
> 
> 
>  * Website: http://juliencoder.de - for summer is a state of sound
>  * SoundCloud: https://soundcloud.com/jeanette_c
>  * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
>  * GitHub: https://github.com/jeanette-c
>  * Twitter: https://twitter.com/jeanette_c_s
> 
> But now I'm stronger than yesterday <3
> (Britney Spears)
> 

Hi,
you could try this software instead, if you are using a shuffle:
https://aur.archlinux.org/packages/ipod-shuffle-4g/

About the dependency:
It seems it is not available anymore in the repos/aur. But the software
is also a bit older, you might want to consider using another software
like I mentioned?

Nico

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] Sébastien Luttringer and Tobias Powalowski

[NicoHood]

On 07/03/2017 12:21 AM, Morten Linderud wrote:
> On Mon, Jul 03, 2017 at 12:16:53AM +0200, NicoHood wrote:
>> On 07/03/2017 12:07 AM, Morten Linderud wrote:
>>> On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote:
>>>> Yes the GPG signature of the tag commit is checked. However you can
>>>> attack the git metadata and set a tag to a different commit. If this
>>>> commit is signed, but at an older stage which is vulnearable, we have an
>>>> issue. Just one example. So we should always also secure the transport
>>>> layer.
>>>> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
>>>>
>>>
>>> The sign includes the hash. You would essentially have to trick Lennart 
>>> into replacing the tag to a different commit,
>>> and sign the tag. Creating a vulnerable but verified source for the 
>>> PKGBUILD. At this point i think we have bigger
>>> problems then whatever the PKGBUILD is doing...
>>>
>>
>> Thats is exactly what I mean. If I understood right you can modify the
>> git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
>> is gpg signed and all valid. This seems to work for me.
>>
> 
> But at this point you can't trust critical maintainers of important software. 
> This isn't a threat model i think
> PKGBUILDs (or Arch for that matter) really cares about. Am i wrong? Or are 
> you implying MITM attacks can trick the
> packager into packaging broken software?
> 
> 

Sure it is all about MITM, as we are talking about using https over
http. I am not sure if I am right. But why are we even discussing if
https is available? It will just make things better.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Sébastien Luttringer and Tobias Powalowski

[NicoHood]

On 07/03/2017 12:07 AM, Morten Linderud wrote:
> On Sun, Jul 02, 2017 at 11:55:35PM +0200, NicoHood wrote:
>> Yes the GPG signature of the tag commit is checked. However you can
>> attack the git metadata and set a tag to a different commit. If this
>> commit is signed, but at an older stage which is vulnearable, we have an
>> issue. Just one example. So we should always also secure the transport
>> layer.
>> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias
>>
> 
> The sign includes the hash. You would essentially have to trick Lennart into 
> replacing the tag to a different commit,
> and sign the tag. Creating a vulnerable but verified source for the PKGBUILD. 
> At this point i think we have bigger
> problems then whatever the PKGBUILD is doing...
> 

Thats is exactly what I mean. If I understood right you can modify the
git metadata in a way that you can pull tag 1.2 but get 1.0. And tag 1.0
is gpg signed and all valid. This seems to work for me.

I've added sangy to this email, he is the author of this presentation
and should know best. sangy, can you please give us some more detailed
information if an attack could still compromise the systemd package with
a modified git source but still gpg signed commits?

~Nico



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Sébastien Luttringer and Tobias Powalowski

[NicoHood]

On 07/02/2017 11:38 PM, Eli Schwartz wrote:
> Let's make this clear: None of these claims are true! At all! Not even
> one of them!

You just say its not true, but that is wrong. I've wrote a statement for
every link he pointed out in which way it is valid or not.

> You have grabbed the troll bait! Please don't do that. Also, you're wrong.

You are also a troll, as you just block with "STOP TROLLING". That is
even more annoying to me.

> Posting about these packages and attempting to shame their maintainers
> on the mailing list is unacceptable, in the way posting to the mailing
> list about the chemical composition of peanut butter is unacceptable.

Yes, we should not shame specific people, I've learned this myself. He
picked a few packages from few maintainers. We DO have SERIOUS security
issues in PGBUILDs that we CAN fix, but just dont, because of no obvious
reason.

> systemd is validated with GPG, it doesn't matter whether the download
> transport is checked against the cacert system. GPG already ensures that
> this package cannot sneakily use a source that isn't signed with the
> validpgpkeys.

Yes the GPG signature of the tag commit is checked. However you can
attack the git metadata and set a tag to a different commit. If this
commit is signed, but at an older stage which is vulnearable, we have an
issue. Just one example. So we should always also secure the transport
layer.
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias

You are just complaining the loudest. Doesnt mean you are right, nor
better. If we just fix our PKGBUILDs, noone can troll.

How do you think can we improve the PKGBUILD security if we reject
suggestions like this? What would be your plan? Waiting for an attacker
to proof that we should have fixed our PKGBUILDs earlier?



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Sébastien Luttringer and Tobias Powalowski

[NicoHood]

On 07/02/2017 11:05 PM, Martin Kühne via arch-general wrote:
> On Sun, Jul 2, 2017 at 10:39 PM, NicoHood <archli...@nicohood.de> wrote:
>> So why are we so resistant against those suggestions? Those are good and
>> valid, no matter who this guy is and how he interacts with people. From
>> the technical point of view he is right. And we all should care for our
>> users, because we are responsible for them.
> 
> https://lists.archlinux.org/pipermail/arch-general/2017-July/043860.html
> 
> You know I thought about the factuality part of the emails writing my
> response too, and it turned out I couldn't criticise the content for
> anything but harshness. This is going to an interesting place, and
> we'll have to decide how we can deal with content like this in a way
> that tells the source to go f themselves while paying actual attention
> to valid criticism...
> 
> cheers!
> mar77i
> 

You are right. I think this has all its past and we should just go on
and fix our Distribution. He reminds me a bit of Torvalds, from what
I've heard. It has its pro and its cons.

We should use those suggestions, as they are really helpful. Actually it
is really good to have someone carefully reviewing and watching our
PKGBUILDs.

As another idea we maybe could consider to write more precise PKGBUILD
standards for security measures, which e.g. define that HTTPS must be
used, whenever available etc. This way people like him can be of a huge
help and we can improve our PKGBUILD security continuously. This would
help everyone. How about that?

~Nico



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Sébastien Luttringer and Tobias Powalowski

[NicoHood]

On 07/02/2017 10:18 PM, Eli Schwartz via arch-general wrote:
> On 07/02/2017 04:12 PM, User via arch-general wrote:
>> Sébastien Luttringer, 
>> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/btrfs-progs=959539e1f7df15986f336bb03225ea796a44ca3e
>>  , 
>> https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums.asc,
>>  
>> https://lists.archlinux.org/pipermail/arch-general/2016-December/042700.html 
>> .
>> Tobias Powalowski, 
>> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/hdparm=2bd43d6fec063156c40dfc0d5ba115155b09cfc1
>>  , i waited and no one said anything all this time. you do not help each 
>> other.
> 
> So basically, you are confirming you are fnodeuser?
> 
> I guess you thought this was a good way to get around being blacklisted
> from the mailing list due to continuous rudeness and spammy behaviour.
> 

I've checked the links and while those suggestions are a bit harsh, they
are still valid:

* btrfs-progs can use stronger hashes. This always makes sense and can
be changed within seconds. Especially because upstream hashes are
available for comparison beside the Signature.
* The suggestion to add sha2 hashes for the .iso download is valid.
There is no good reason why to not also add another (more secure)
algorithm, no matter if the current solution might be okay today, but
maybe not in the future.
* The last link shows a real issue of the PKGBUILD. The sha512 values
are wrong and on top of that the variable name is misspelled (double
ss). This should be fixed and only contains sha512sums or both

No matter who he is, he is right. Also with his previous email, we
should build systemd with https sources. If we ever have malicious
software in our Distribution we will get lots of trouble. And we dont
want this to happen just because we did not apply such an obvious fix.

So why are we so resistant against those suggestions? Those are good and
valid, no matter who this guy is and how he interacts with people. From
the technical point of view he is right. And we all should care for our
users, because we are responsible for them.

~Nico



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 <subscript...@binkmail.com> 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

[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

[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

[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

[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

[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

[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

[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