[pass] Killing plaintext git:// in favor of https:// cloning
brian at minton.name
Tue Feb 23 14:53:56 CET 2016
Certainly got can sign individual tags with an OpenPGP key. Each commit is
also hashed and the hashes are known. If you sign every commit, or at least
every release, the code can't be tampered with. This is the workflow of,
for instance, the Linux kernel. That being said, with free TLS certificates
from letsencrypt, I'd expect lots of sites to switch to https. For one
thing, it's more versatile, since authorized users can push as well. With
the git:// protocol, users can only pull.
On Tue, Feb 23, 2016, 12:08 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong <normalperson at yhbt.net> wrote:
> > I suggest keeping git:// running as automated mirrors may not be
> > monitored very closely or easily updated.
> That's a good point. I'd forgotten about automated mirrors. I'll keep
> logs of the git:// pulls for a month or so and see if there are any
> regular pullers and also if I can track down the source IP. Perhaps
> it's a manageable pool of people to switch over.
> > git already has plenty of integrity checking built-in and
> > getting the proper hashes for the heads/tags over a
> > trusted-enough medium is enough (or reading the fine code).
> No, git's built-in integrity protection really is not sufficient if
> the transport is compromised.
> > And as others have said, HTTPS isn't impenetrable
> I'd like some specific details on this repeated claim.
> > the CA system is still a major problem.
> True. But there doesn't appear to be a widely deployed alternative.
> > Also, TLS libraries can introduce new bugs and vulnerabilities
> > like Heartbleed.
> This is true, but I already require a public TLS deployment, so it's
> there regardless.
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Password-Store