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/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. > 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
Attachment:
signature.asc
Description: PGP signature
