Héctor Orón Martínez writes ("Bug#906317: dgit: consider demoting
git-buildpackage to recommends"):
> For some background, I would like to enable Debian porterbox users
> to be able to run `dgit push`, however some of my colleagues on the
> Debian sysadmin team, consider installing `dgit` a concern, since
> they prefer users to push sources into porterboxes rather than pull
> them (being `apt source` the only exception). At the moment `dgit`
> is installed in porterboxes,
It is great that dgit is installed in porterboxes, thanks.
During conversations at DC18, I was asked about dgit's approach to the
integrity of the sources it fetches. I mentioned this bug:
#790093 dgit is subvertable by X.509 CA cabal
This is not as bad on porterboxes (which AIUI trust only Let's
Encrypt) as it is on general user machines, but it is still
suboptimal. And we should improve this for user machines too.
I think now would be a good time to look at #790093 again. Would
anyone from the DSA team with the requisite TLS knowledge be available
to get together with me to sketch out a solution ?
The basic problem statement is as follows:
dgit needs to use the ftpmaster api service for a lot of its
functions. (It is not really practical to replace this with
reliance on apt; I can expand on the reasons if need be.)
The ftpmaster api service is currently provided over HTTP over TLS,
based on with a standard X.509 web PKI cert from Let's Encrypt.
We want, instead, those API queries to be secured by a public key
shipped in a Debian packge.
dgit currently uses the system-provided curl with no special TLS
options (but could pass such options if we knew what they should be).
The description in the head message in #790093 about EE certificates
is no longer right (if it ever was). AIUI nowadays the EE certificate
is from LE and is updated frequently - too frequently for a Debian
package.
Maybe that means that the ftpmaster api service needs to be provided
via another HTTP-over-TLS endpoint with a different TLS setup.
NB that although I am a security expert and have a background
incryptography, I don't really know much about the details of TLS and
X.509. So some of what I say above about TLS and X.509 may be wrong.
Thanks,
Ian.
