Limiting who can create v${NUMBER}.${NUMBER}.${NUMBER} tags in KDE Applications git repos

[Christian Mollekopf]

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 at 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