Sébastien Luttringer, https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/btrf... , 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/hdpa... , i waited and no one said anything all this time. you do not help each other.
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/btrf... , 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/hdpa... , 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.
Am 02.07.2017 um 22:18 schrieb Eli Schwartz via arch-general:
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/btrf... , 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/hdpa... , 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.
Oh, please dont feed the troll… its exactly what he's aiming for.
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. :)
On Sun, 2 Jul 2017 16:18:23 -0400, Eli Schwartz via arch-general wrote:
So basically, you are confirming you are fnodeuser?
IMO it's better not to reply to her/him and instead to inform arch-general-owner@archlinux.org , just in case it wasn't already noticed.
https://lists.archlinux.org/pipermail/arch-general/2017-July/043853.html https://lists.archlinux.org/pipermail/arch-general/2017-July/043854.html
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/btrf... , 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/hdpa... , 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 Sun, Jul 2, 2017 at 10:39 PM, NicoHood archlinux@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
On 07/02/2017 11:05 PM, Martin Kühne via arch-general wrote:
On Sun, Jul 2, 2017 at 10:39 PM, NicoHood archlinux@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
I stand corrected which leaves only part of my last sentence. Thanks for the detailed heads-up, everyone, especially Eli.
On Sun, Jul 2, 2017 at 11:05 PM, Martin Kühne mysatyre@gmail.com wrote:
we'll have to decide how we can deal with content like this in a way that tells the source to go f themselves [content is hereby retracted]...
have a good night and new week, everyone. except User: go f yourself.
cheers! mar77i
... 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.
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/presen...
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?
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...
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.
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
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?
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.
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.
(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?)
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.
(Mon, Jul 03, 2017 at 01:06:04AM +0200) Morten Linderud :
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.
I didn’t imply that, but it’s easy to rely on the "gpg check" to skip other checks.
I never faced the problem, but right out of my mind I don’t know how to download a git project archive and check easily that I got the correct tag.
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.
(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
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
Then you rely only on that last two things
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 lennart@poettering.net 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 lennart@poettering.net" [unknown] gpg: aka "Lennart Poettering lennart@poettering.de" [unknown] gpg: aka "Lennart Poettering (Red Hat) lpoetter@redhat.com" [unknown] gpg: aka "Lennart Poettering (Sourceforge.net) poettering@users.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.
Il 03/07/2017 04:14, Eli Schwartz via arch-general ha scritto:
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 <lennart@poettering.net> 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 <lennart@poettering.net>" [unknown] gpg: aka "Lennart Poettering <lennart@poettering.de>" [unknown] gpg: aka "Lennart Poettering (Red Hat) <lpoetter@redhat.com>" [unknown] gpg: aka "Lennart Poettering (Sourceforge.net) <poettering@users.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 85B0I 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.
I think I can reply to this. Just skip if not interesed to last part.
"""Thanks""" to a lab of a class I had the previous semester, I can describe you exactly how Git blobs are... There are: - normal *blob*s: standard files compressed using Deflate, have only a small special header at the top - *tree*s: a specially encoded file, pointing to blobs or other *tree*s... call them *blobbed directories* - *commits*: another deflated file, keeping the commit message and a reference to a *tree*. To be 100% I made one just now to check and I can say that we have - *tags*: a plain file referring to a commit object
You see the point: you just renamed a text file pointing others. Unless you change the commit binary file (doing this won't pass the gpg check) or fake the whole .git blobs, it will point to the v233 commit and all the stuff below it. If you are instead saying that Git should notice that the file in the refs folder is named improperly, just `man git` and see what *git* is :P :D
tl;dr: Too much an hassle; destroying a Git repo is easy, faking it is not.
P.S. Thanks to that class, we made some Java classes to handle Git blobs, check them if you want: https://gitlab.com/ItachiSan/lab01/
On 3 July 2017 at 01:22, Eli Schwartz via arch-general arch-general@archlinux.org 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.
On Sun, 2 Jul 2017 22:39:37 +0200, NicoHood wrote:
I've checked the links and while those suggestions are a bit harsh, they are still valid:
- btrfs-progs can use stronger hashes.
Hi,
the subject doesn't mention that "btrfs-progs can use stronger hashes", the subject actually is "Sébastien Luttringer and Tobias Powalowski". If you want to discuss a possible issue, open a new thread for e.g. "btrfs-progs can use stronger hashes".
I didn't care about the links, since even without Eli's hint it was clear that this person is a known spammer.
Florian has moderated her/his new account. Next time we simply should sent an off-list mail to arch-general-owner@archlinux.org .
On Sun, 2 Jul 2017 23:30:15 +0200, NicoHood wrote:
He reminds me a bit of Torvalds, from what I've heard.
I haven't heard rumours about Linus Torvalds using disposable emails. Perhaps "User <registrationhell..." is Linus Torvalds ;).
Regards, Ralf
arch-general@lists.archlinux.org