* 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
* [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
* [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).