[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Limiting who can create v${NUMBER}.${NUMBER}.${NUMBER} tags in KDE Applications git repos
From:       Christian Mollekopf <chrigi_1 () fastmail ! fm>
Date:       2018-06-25 11:22:19
Message-ID: 1529925739.2016889.1419389720.3D048BD6 () webmail ! messagingengine ! com
[Download RAW message or body]

On Mon, Jun 25, 2018, at 10:56 AM, Rolf Eike Beer wrote:
> Ben Cooksley wrote:
> > On Mon, Jun 25, 2018 at 6:57 PM, Rolf Eike Beer
> > <kde@opensource.sf-tec.de> wrote:
> > > Am 2018-06-24 22:56, schrieb Albert Astals Cid:
> > > > 
> > > > Hi, would anyone be against limiting who can create
> > > > v${NUMBER}.${NUMBER}.${NUMBER}
> > > > i.e. tags that look like our release tags to members of the release 
> > > > team
> > > > for
> > > > the KDE Applications git repositories?
> > > > 
> > > > Rationale: Some distros build from git tags so creating a "release 
> > > > looking
> > > > tag" is for them like "using the release tarball" and we already 
> > > > limit who
> > > > can
> > > > upload release tarballs to the download.kde.org so it would be a 
> > > > similar
> > > > restriction but for the git side.
> > > 
> > > 
> > > This sounds sane to me. Simply require those tags to be signed by
> > > $key_in_known_good_list.
> > 
> > Given the recent security issues surrounding interaction with GPG done
> > by external programs, I would rather not perform key verification.
> 
> Which one do you mean? The EFFfail one, that was about tricking mail 
> clients into data exfiltration (which is not relevant here)? The one 
> where the embedded filename was not properly sanitized (CVE-2018-12020) 
> and every distro should already have a patch deployed? Or the side 
> channel attacks to recover the private key that is not on the git 
> machine at all?
> 
> Sorry, but not doing GnuPG is always the worse option.
> 

Having looked at the EFAIL vulnerability in particular I agree I see no reason to not \
do key verification. Any processing in principle has potential for vulnerabilities, \
but verifying a signature with a public key is IMO not any more dangerous than any \
other arbitrary operation or script.

Cheers,
Christian


[prev in list] [next in list] [prev in thread] [next in thread]