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