* Killing plaintext git:// in favor of https:// cloning @ 2016-02-22 18:16 Jason 2016-02-22 18:22 ` Jason ` (4 more replies) 0 siblings, 5 replies; 12+ messages in thread From: Jason @ 2016-02-22 18:16 UTC (permalink / raw) Hello projects-with-mailing-lists, Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of the plaintext git:// endpoint for cloning. This means: git clone git://git.zx2c4.com/cgit --> git clone https://git.zx2c4.com/cgit git clone git://git.zx2c4.com/password-store --> git clone https://git.zx2c4.com/password-store Does anybody have any objections or comments? Thanks, Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-22 18:16 Killing plaintext git:// in favor of https:// cloning Jason @ 2016-02-22 18:22 ` Jason 2016-02-22 19:18 ` mailings ` (3 subsequent siblings) 4 siblings, 0 replies; 12+ messages in thread From: Jason @ 2016-02-22 18:22 UTC (permalink / raw) Well, uh oh speghettio! Looks like somebody has published in paper the git:// URI: https://books.google.fr/books?id=kJsQAwAAQBAJ&pg=PA314&lpg=PA314&dq=git://git.zx2c4.com&source=bl&ots=W6M9TlYzCY&sig=g-PY0glN2ddWygtFDLiHgbiC69I&hl=en&sa=X&redir_esc=y#v=onepage&q=git%3A%2F%2Fgit.zx2c4.com&f=false Perhaps there's a way to write a dummy daemon that prints a message... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-22 18:16 Killing plaintext git:// in favor of https:// cloning Jason 2016-02-22 18:22 ` Jason @ 2016-02-22 19:18 ` mailings 2016-02-22 19:56 ` Jason 2016-02-23 1:19 ` normalperson ` (2 subsequent siblings) 4 siblings, 1 reply; 12+ messages in thread From: mailings @ 2016-02-22 19:18 UTC (permalink / raw) On 22/02/16 19:16, Jason A. Donenfeld wrote: > Hello projects-with-mailing-lists, > > Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of > the plaintext git:// endpoint for cloning. > > This means: > > git clone git://git.zx2c4.com/cgit > --> > git clone https://git.zx2c4.com/cgit > > git clone git://git.zx2c4.com/password-store > --> > git clone https://git.zx2c4.com/password-store > > > Does anybody have any objections or comments? > Yes, why? What's the point? The repos are public, so cloning them over https bring nothing, except extra overhead and server load. > Thanks, > Jason > _______________________________________________ > CGit mailing list > CGit at lists.zx2c4.com > http://lists.zx2c4.com/mailman/listinfo/cgit > -- Ferry Huberts ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-22 19:18 ` mailings @ 2016-02-22 19:56 ` Jason 0 siblings, 0 replies; 12+ messages in thread From: Jason @ 2016-02-22 19:56 UTC (permalink / raw) On Mon, Feb 22, 2016 at 8:18 PM, Ferry Huberts <mailings at hupie.com> wrote: > Yes, why? > What's the point? So that the contents of the repository cannot be modified in transit. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-22 18:16 Killing plaintext git:// in favor of https:// cloning Jason 2016-02-22 18:22 ` Jason 2016-02-22 19:18 ` mailings @ 2016-02-23 1:19 ` normalperson 2016-02-23 1:28 ` Jason 2016-02-23 5:08 ` Jason 2016-02-24 19:00 ` hacking 2016-02-25 17:21 ` Jason 4 siblings, 2 replies; 12+ messages in thread From: normalperson @ 2016-02-23 1:19 UTC (permalink / raw) "Jason A. Donenfeld" <Jason at zx2c4.com> wrote: > Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of > the plaintext git:// endpoint for cloning. > Does anybody have any objections or comments? I suggest keeping git:// running as automated mirrors may not be monitored very closely or easily updated. 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). And as others have said, HTTPS isn't impenetrable and the CA system is still a major problem. Also, TLS libraries can introduce new bugs and vulnerabilities like Heartbleed. Quoting from http://www.postfix.org/TLS_README.html | By turning on TLS support in Postfix, you not only get the | ability to encrypt mail and to authenticate remote SMTP clients | or servers. You also turn on thousands and thousands of lines of | OpenSSL library code. Assuming that OpenSSL is written as | carefully as Wietse's own code, every 1000 lines introduce one | additional bug into Postfix. Something to keep in mind :) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-23 1:19 ` normalperson @ 2016-02-23 1:28 ` Jason 2016-02-23 5:08 ` Jason 1 sibling, 0 replies; 12+ messages in thread From: Jason @ 2016-02-23 1:28 UTC (permalink / raw) https://git.zx2c4.com/git-daemon-dummy/about/ I just wrote this. Will consider whether or not to deploy it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-23 1:19 ` normalperson 2016-02-23 1:28 ` Jason @ 2016-02-23 5:08 ` Jason 2016-02-23 6:21 ` normalperson [not found] ` <CANyOob14C3cZuwkQBpEv=Tr==KY=oULyUg7NX3B6vb8mfRkgDg@mail.gmail.com> 1 sibling, 2 replies; 12+ messages in thread From: Jason @ 2016-02-23 5:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-23 5:08 ` Jason @ 2016-02-23 6:21 ` normalperson [not found] ` <CANyOob14C3cZuwkQBpEv=Tr==KY=oULyUg7NX3B6vb8mfRkgDg@mail.gmail.com> 1 sibling, 0 replies; 12+ messages in thread From: normalperson @ 2016-02-23 6:21 UTC (permalink / raw) "Jason A. Donenfeld" <Jason at zx2c4.com> wrote: > On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong <normalperson at yhbt.net> wrote: > > 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. git commits, tags, and request-pull-formatted emails (with unabbreviated commit IDs) may all be signed with GPG. Once those are verified, "git fsck" results can be trusted. > > And as others have said, HTTPS isn't impenetrable > > I'd like some specific details on this repeated claim. The known problem would be CAs being compromised. I've also heard of MITM stripping proxies; but don't know much about them. > > the CA system is still a major problem. > > True. But there doesn't appear to be a widely deployed alternative. GPG-signed tags/commits/emails. Probably not as widely deployed as TLS CAs, but probably sufficient in Free Software circles. > > 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. Vulnerabilities may affect clients, too (for example, the recent OpenSSH roaming vulnerability). IMHO, users should be given a choice of which poison to pick. Disclaimer: Personally, I don't GPG sign anything, myself, either. For selfish reasons, I do not want people to trust me or my signature and would prefer they read and scrutinize what little I write. And we can't rule out undiscovered vulnerabilties affecting GPG, either. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CANyOob14C3cZuwkQBpEv=Tr==KY=oULyUg7NX3B6vb8mfRkgDg@mail.gmail.com>]
* [pass] Killing plaintext git:// in favor of https:// cloning [not found] ` <CANyOob14C3cZuwkQBpEv=Tr==KY=oULyUg7NX3B6vb8mfRkgDg@mail.gmail.com> @ 2016-02-23 14:03 ` Jason [not found] ` <CANyOob1KEfFd5-e5e9ETauvmakEiK7pU5083-7t8CzTW5-QrKQ@mail.gmail.com> 0 siblings, 1 reply; 12+ messages in thread From: Jason @ 2016-02-23 14:03 UTC (permalink / raw) On Tue, Feb 23, 2016 at 2:53 PM, Brian Minton <brian at minton.name> wrote: > 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. False. Commits in Linux development are not routinely signed. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CANyOob1KEfFd5-e5e9ETauvmakEiK7pU5083-7t8CzTW5-QrKQ@mail.gmail.com>]
* [pass] Killing plaintext git:// in favor of https:// cloning [not found] ` <CANyOob1KEfFd5-e5e9ETauvmakEiK7pU5083-7t8CzTW5-QrKQ@mail.gmail.com> @ 2016-02-23 14:34 ` Jason 0 siblings, 0 replies; 12+ messages in thread From: Jason @ 2016-02-23 14:34 UTC (permalink / raw) Yes, releases are. Obviously this conversation extends to much more than releases, though. I sign tags too: https://git.zx2c4.com/cgit/tag/?h=v0.12 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-22 18:16 Killing plaintext git:// in favor of https:// cloning Jason ` (2 preceding siblings ...) 2016-02-23 1:19 ` normalperson @ 2016-02-24 19:00 ` hacking 2016-02-25 17:21 ` Jason 4 siblings, 0 replies; 12+ messages in thread From: hacking @ 2016-02-24 19:00 UTC (permalink / raw) On 02/22/2016 07:16 PM, Jason A. Donenfeld wrote: > Does anybody have any objections or comments? git:// should be removed from clone urls Cheers Daniel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Killing plaintext git:// in favor of https:// cloning 2016-02-22 18:16 Killing plaintext git:// in favor of https:// cloning Jason ` (3 preceding siblings ...) 2016-02-24 19:00 ` hacking @ 2016-02-25 17:21 ` Jason 4 siblings, 0 replies; 12+ messages in thread From: Jason @ 2016-02-25 17:21 UTC (permalink / raw) Welp, in the last 2 days: krantz log # grep git-daemon messages | grep 'Connection from' | wc -l 3079 So, I guess git:// will be sticking around, alas. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-02-25 17:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-22 18:16 Killing plaintext git:// in favor of https:// cloning Jason 2016-02-22 18:22 ` Jason 2016-02-22 19:18 ` mailings 2016-02-22 19:56 ` Jason 2016-02-23 1:19 ` normalperson 2016-02-23 1:28 ` Jason 2016-02-23 5:08 ` Jason 2016-02-23 6:21 ` normalperson [not found] ` <CANyOob14C3cZuwkQBpEv=Tr==KY=oULyUg7NX3B6vb8mfRkgDg@mail.gmail.com> 2016-02-23 14:03 ` [pass] " Jason [not found] ` <CANyOob1KEfFd5-e5e9ETauvmakEiK7pU5083-7t8CzTW5-QrKQ@mail.gmail.com> 2016-02-23 14:34 ` Jason 2016-02-24 19:00 ` hacking 2016-02-25 17:21 ` Jason
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).