On 07/02/2017 04:21 PM, G. Schlisio wrote:

Oh, please dont feed the troll… its exactly what he's aiming for.

I thought it was important that everyone know exactly who they are dealing with (because he has a lot of history here and has now progressed to hiding his name/handle). Otherwise I wouldn't have replied at all. So yeah, the fact that this is fnodeuser again is the only observation I have to make this time. :) -- Eli Schwartz

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&id=959539e1f7df15986f336bb03225ea796a44ca3e , https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/sha256sums...., 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&id=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

On 07/02/2017 11:05 PM, Martin Kühne via arch-general wrote:

On Sun, Jul 2, 2017 at 10:39 PM, NicoHood 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

... so, apparently, people are determined to actually fall for this clown. I was initially going to send this off-list, but I'd just like to shut down these claims fast before people start falling for it. We already had two people fall for it, people whose opinions I am not generally inclined to disrespect. Let's make this clear: None of these claims are true! At all! Not even one of them! On 07/02/2017 04:39 PM, NicoHood wrote:

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

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

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

Calling out specific package *maintainers* for a public shaming is always unacceptable, and picking on specific packages for the sake of something that only makes sense in the context of a *distro-wide* policy makes NO SENSE. Lots of things can use stronger hashes, in theory. We have ridden this hobby-horse all over arch-general, repeatedly, as you should know due to having contributed no small part of that conversation yourself. I am sick and tired of hearing you and others reignite that debate every time someone mentions the word "checksums", you aren't contributing any useful discussion about policy anymore. 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.

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

Stop being ludicrous. No one believes that you need two different hashes, sha256 is completely acceptable, end of story, and quite frankly, we use GPG signatures there so CRC checksums are all we need (and sha256 is way overkill but we have them anyway, so congrats). Are you genuinely trying to tell me you think there is something you haven't already said last time, which you think is useful to say regarding a potential *distro policy* ?

* 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

That PKGBUILD is ugly in the extreme due to containing junk variables that do not exist in any sense of pacman's source build systems, but it also only contains md5sums. Valid md5sums. Stop spreading FUD. This package therefore falls under the category of "attempted public shaming of packages using md5sums", and also "attempted public shaming of a specific *person* for making a stupid typo". This is not a valid point, this is exclusively rudeness with the explicit attempt to be rude. And you've fallen for it, hook, line, and sinker.

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.

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.

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.

Because he has been banned from the forums, from IRC, from the bugtracker, and from the mailing list due to extreme rudeness that makes him intolerable to talk to, and also because he is wrong or a liar, more often than he is right. And because you just fell for him, as many well-meaning people who aren't familiar with him do. -- Eli Schwartz

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

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... -- Morten Linderud PGP: 9C02FF419FECBE16

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

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? -- Morten Linderud PGP: 9C02FF419FECBE16

On Mon, Jul 03, 2017 at 12:25:22AM +0200, NicoHood wrote:

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

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.

But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life. Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS. You also didn't really reply about the threat model. -- Morten Linderud PGP: 9C02FF419FECBE16

On Mon, Jul 03, 2017 at 01:01:35AM +0200, Ismael Bouya wrote:

(Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud :

...

But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life. Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.

You also didn't really reply about the threat model.

If I understand correctly what Nicohood meant, what could happen is that version X of systemd (or anything else) has a well known vulnerability, fixed in X+1. X+1 is packaged, so anyone up to date thinks "good I'm safe now". But since a man in the middle can force to download version X (signed by the systemd maintainer so considered "secure"), he can force you to download that version when you create the package and you'll think you have the safe version while having the unsafe one.

If that happens to the packager in archlinux, then you poisoned all archlinux users.

(but then, the md5sum will be wrong anyway?) -- Ismael

At this point we can't trust the trusted users to build and verify the correct packages, let alone maintaine a safe infrastructure to build packages. This is a slippery slope, and i really fucking hope this isn't a serious issue any devs or TUs are afraid of. -- Morten Linderud PGP: 9C02FF419FECBE16

On 07/02/2017 07:01 PM, Ismael Bouya wrote:

(Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud :

...

But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life. Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.

You also didn't really reply about the threat model.

If I understand correctly what Nicohood meant, what could happen is that version X of systemd (or anything else) has a well known vulnerability, fixed in X+1. X+1 is packaged, so anyone up to date thinks "good I'm safe now". But since a man in the middle can force to download version X (signed by the systemd maintainer so considered "secure"), he can force you to download that version when you create the package and you'll think you have the safe version while having the unsafe one.

Okay, this I am genuinely curious about. In what circumstances can I have: - the systemd repository cloned over the git:// protocol - an annotated tag for systemd v233 signed by Lennart Poettering. - an annotated tag for systemd v232 signed by Lennart Poettering. - a man in the middle attack - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG ${fingerprint} that matches with Lennart's known GPG fingerprint as recorded in validpgpkeys And as a result, when I run the git command `git checkout refs/tags/v233`, I am tricked into getting v232 instead which contains a vulnerability. Also, I wouldn't be alerted by the verbose printing of the systemd version which happens during the boot process, nor by $systemd_binary --version ... Because I don't think git works that way, but I am willing to be proven wrong. Also I bet the git developers would be fascinated to hear the details, you might even get some sort of bounty for successfully hacking git like that. -- Eli Schwartz

On 07/02/2017 07:34 PM, Ismael Bouya wrote:

(Sun, Jul 02, 2017 at 07:22:23PM -0400) Eli Schwartz via arch-general :

...

Okay, this I am genuinely curious about.

In what circumstances can I have: - the systemd repository cloned over the git:// protocol - an annotated tag for systemd v233 signed by Lennart Poettering. - an annotated tag for systemd v232 signed by Lennart Poettering. - a man in the middle attack - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG ${fingerprint} that matches with Lennart's known GPG fingerprint as recorded in validpgpkeys

And as a result, when I run the git command `git checkout refs/tags/v233`, I am tricked into getting v232 instead which contains a vulnerability.

Until there, it's exactly the topic of the presentation linked by Nicohood

So I was under the impression that git tags encode the tagname in the actual blob, and I didn't see how that attack (rooted in the basic nature of a branch as a lightweight, mutable, *pushable* pointer to a commit) was supposed to work unless of course it was talking about a lightweight tag (which is not really meant for public/permanent use)... Having actually tested this out, I find myself quite bewildered. Because, git *does* encode the tagname in the blob, like I thought. And... you *can* simply copy .git/refs/tags/tagname to create a fake tag, and then you see something quite bewildering: ``` [eschwartz@arch ~/git]$ git clone https://github.com/systemd/systemd [...] [eschwartz@arch ~/git]$ cd systemd [eschwartz@arch ~/git/systemd]$ echo "$(git show-ref -s v233)" > .git/refs/tags/v232 [eschwartz@arch ~/git/systemd]$ git tag -v v232 object d60c527009133a1ed3d69c14b8c837c790e78d10 type commit tag v233 tagger Lennart Poettering 1488405946 +0100 systemd 233 gpg: Signature made Wed 01 Mar 2017 05:05:46 PM EST gpg: using RSA key B63B21879C3485B0 gpg: Good signature from "Lennart Poettering " [unknown] gpg: aka "Lennart Poettering " [unknown] gpg: aka "Lennart Poettering (Red Hat) " [unknown] gpg: aka "Lennart Poettering (Sourceforge.net) " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 63CD A1E5 D3FC 22B9 98D2 0DD6 327F 2695 1A01 5CC4 Subkey fingerprint: 16B1 C4EE C0BC 021A C777 F681 B63B 2187 9C34 85B0 ``` I simply do not understand why git doesn't error when it sees that a tag ref named v232 points to a tag blob named v233. The information is all there, and it seems trivial to add a check. Oh well, one more reason to use commit hashes rather than pkgver tags. (The other reason is, because upstreams themselves are quite capable of modifying tags and re-signing them without waiting for some attacker to play with the ref pointers.) Anyway, I learned something today. -- Eli Schwartz

On 3 July 2017 at 01:22, Eli Schwartz via arch-general wrote:

On 07/02/2017 07:01 PM, Ismael Bouya wrote:

...

(Mon, Jul 03, 2017 at 12:29:44AM +0200) Morten Linderud :

...

But HTTPS doesnt matter here. We have a trusted signer inn the PKGBUILD, anyone can MITM for the good of their life. Unless they can fake the signature (Hint; they cant), or trick Lennart into signing something he shouldnt (Hint; he wont), we don't have a case here. It doesn't really matter if its HTTP or HTTPS.

You also didn't really reply about the threat model.

If I understand correctly what Nicohood meant, what could happen is that version X of systemd (or anything else) has a well known vulnerability, fixed in X+1. X+1 is packaged, so anyone up to date thinks "good I'm safe now". But since a man in the middle can force to download version X (signed by the systemd maintainer so considered "secure"), he can force you to download that version when you create the package and you'll think you have the safe version while having the unsafe one.

Okay, this I am genuinely curious about.

In what circumstances can I have: - the systemd repository cloned over the git:// protocol - an annotated tag for systemd v233 signed by Lennart Poettering. - an annotated tag for systemd v232 signed by Lennart Poettering. - a man in the middle attack - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG ${fingerprint} that matches with Lennart's known GPG fingerprint as recorded in validpgpkeys

And as a result, when I run the git command `git checkout refs/tags/v233`, I am tricked into getting v232 instead which contains a vulnerability. Also, I wouldn't be alerted by the verbose printing of the systemd version which happens during the boot process, nor by $systemd_binary --version

...

Because I don't think git works that way, but I am willing to be proven wrong. Also I bet the git developers would be fascinated to hear the details, you might even get some sort of bounty for successfully hacking git like that.

On the other hand, the systemd-stable repo doesn't have signed tags (or commits) and Arch is probably going to move to that since it has post-release fixes for regressions and bugs. -- damjan