Git.io deprecation

https://github.blog/changelog/2022-04-25-git-io-deprecation/

by dmarto • 4 years ago

193 106 4 years ago

ro_bit• 4 years ago

Out of an abundance of caution due to the security of the links redirected with the current git.io infrastructure, we have decided to accelerate the timeline. We will be removing all existing link redirection from git.io on April 29, 2022.

What were the security concerns?

gurjeet• 4 years ago

Perhaps they are selling the domain, or planning to use it for a new service that allows users to create arbitrary URLs. Both of those scenarios can help an attacker take over old git.io URLs

kadoban• 4 years ago

More likely IMO the backend is some old hacky thing that nobody has been maintaining and someone found a vuln or some software stopped getting security updates.

jhugo3• 4 years ago

It's basically unimaginable that they would sell the domain. Whatever amount of money they'd get for it wouldn't be worth it given the potential risks to their customers (since it was formerly an URL shortener), and owning git.io is pretty on-brand for GitHub.

bpeebles• 4 years ago

The read-only post from January said

Today, git.io is increasingly being used for malicious purposes.

So my guess is they observed an increase use of some number of existing git.io URLs (perhaps where the destination URL was squatted on) being actively used for "malicious" things.

zinekeller• 4 years ago

perhaps where the destination URL was squatted on

... how? Git.io only redirects to GitHub, isn't it?

spondyl2• 4 years ago

Annoyingly, the CodeQL analysis github actions make use of git.io as a short link to relevant documentation inside action comments.

Even right now, the action is still using git.io so regardless of this advisory, that seems like something that should be have been fixed some time ago when git.io was initially put into read only mode

Thorrez• 4 years ago

How does that work? This page (and the main linked page) seem to say no new links are able to be created:

https://github.blog/changelog/2022-01-11-git-io-no-longer-ac...

spondyl2• 4 years ago

Presumably they were created some time ago and/or Github created them internally. They're hardcoded links that appear as comments in the actions yml file template and have probably existed for quite some time.

spatulon• 4 years ago

I'll make sure we fix those (I work on CodeQL).

pabs3• 4 years ago

That is a very very short deadline.

upbeat_general• 4 years ago

For a link redirection service I’d hope the depreciation timeline is measured in years not months.

forgotmypw17• 4 years ago

A lesson in Internet tenancy we all learn eventually...

Either you own your domain, hardware, software, data, and network -- or you're a tenant in someone else's domain, at your landlord's complete mercy.

Sometimes it's not a bad deal, especially when it's a small landlord whom you have a connection with, other times it can be a raw deal.

You don't have to own all the pieces, but owning your domain name is crucial to avoiding having the rug pulled out from under you like this.

Jaxkr• 4 years ago

This made me nostalgic, I remember when vanity URL shorteners were the coolest thing you could have. A new one popped up every few days and every company land grabbed for something custom they could use for social media.

Then Twitter updated to make URLs use fewer characters by shortening them on the fly (and showing the original URL to viewers). The URL shortener craze died quickly after.

HellsMaddy• 4 years ago

I feel bad, I just recommended a project use git.io short links a few months ago and they took my advice.

captn3m0• 4 years ago

A dump of the shortlink dataset would be appreciated, even if it was only the links that point to public GitHub repos or gists.

Link-rot is annoying, but GitHub could do better here.

charcircuit2• 4 years ago

Or at least just host an immutable endpoint in a subdirectory if you want to repurpose the domain.

derefr2• 4 years ago

They don't; they want to take down the 99% of git.io links that are pointing to malware / phishing, and they don't want to spend all their time manually culling them.

vemv2• 4 years ago

Feels like a punch in the stomach.

git.io has its place in the world, namely for creating code comments to Github immutable permalinks (that is, with SHA markers) that would otherwise surpass a conventional column limit, making linters complain.

I probably have created dozens of such comments over the years. Now people following those will find nothing.

Folks at github should really reconsider their position. Don't expect loyal consumers to keep their trust when you suck at your very job - namely keeping an immutable historic record.

eloisius2• 4 years ago

That sucks and I know it doesn’t help fix your current situation, but I’ve found it useful to include more context and long comments in commit messages than code comments. If your team knows how to use git blame for archeology, the information tends to stay more cogent to the code, while code comments often go stale.

Gigachad• 4 years ago

It becomes increasingly undiscoverable. Especially after some lint rule changes and the last change becomes the lint fix.

Info going stale seems much worse with commit messages since they can’t even be updated unlike comments.

JohnBooty2• 4 years ago

I generally find code comments much more useful than commit messages. They are of course not mutually exclusive and you can (and should) do both.

9 times out of 10, "why are things the way they are now?" is what I'd like to know.

Occasionally, of course, I would like to know "why things were the way they were x commits ago" and that's when commit messages come in handy. But that's the minority use case for me.

gregmac• 4 years ago

Interesting, I have always viewed those as very different things.

Comments explain non-obvious things. For example, "this is a custom search because it was found to be 2.3x faster than .find() for this use case" or "this is sent as a string for backwards compatibility with ExternalRandomApi v1.2" or just walk through a complex algorithm.

I typically only go into archeology mode for two reasons:

1) I found the source of a bug and want to see when it was introduced and why. This is most helpful to prevent reintroducing an old bug, especially in old code lacking unit tests.

2) Someone wrote code that should have been commented, but wasn't.

aetherspawn• 4 years ago

I think JIRA links are a lot better than huge inline slabs of text in commit messages.

Then you can change them later ie make links to other tickets or leave comments.

chrismorgan4• 4 years ago

The hard column limit and linter complaints are in the wrong here. Long, unbreakable strings exist and are reasonable (with URLs generally being the most common, but not the only), and any linter that insists they not exist is bad.

I would also note, for this particular style of URL, that the long URLs are much more useful, as you can read the ref and the path directly, and perhaps thereby bypass the web entirely. The short URL has to be followed to discern its target.

Aeolun• 4 years ago

The first thing I thought of when I saw this comment is that I’d seen it somewhere before: https://xkcd.com/1172/

mdoms• 4 years ago

No. Use your own URLs or face the very obvious predictable consequences. There is absolutely no reason to add another layer of redirection just to get around your 2-bit linter config.

cormacrelf2• 4 years ago

That’s a bit over the top as you did have a hand in choosing to do that and not to fix linters / ignore those self-inflicted problems, instead opting to use a URL shortener and eventually get burned like everyone else who has ever done this. Their job is not to create an immutable historic record. You were never a customer of git.io. The goal was to shorten links because it was trendy.

vemv2• 4 years ago

I've been a Github customer over 10 years.

If you don't see the value of not breaking contracts (in the API sense), it is clear to me that your opinion isn't qualified.

shkkmo• 4 years ago

After a couple of issues with broken links in code comments, I think the best approach is to link to an archive for the page in question (if public) since that has the original URL and makes the original content at the time of the link available as well.

floodle• 4 years ago

Relying on a cloud-based third party link shortening service is a creative solution to your linting errors, to say the least!

chrismorgan4• 4 years ago

I will continue my attempt to rescue the word “deprecate” from destruction.

Git.io deprecation
As notified in January, we shared our plans to deprecate the service.

This is not deprecation. This is discontinuation.

Deprecation is when you say “we recommend not using this, but it’s still working for now”; at time of deprecation, a schedule of when it will cease to work may be provided, or it could be that it will continue to work indefinitely.

The announcement in January was the deprecation. What they’re doing now is the final discontinuation.

BoorishBears4• 4 years ago

If you want to be pedantic you need to also be fully correct.

This announcement in itself is a deprecation, just like the last one, that additionally announces a future discontinuation.

There is no requirement a deprecated service still works.

If something is half broken you can deprecate it for those relying on the half-broken mess and eventually discontinue it (which is what Github is doing)

Brian_K_White• 4 years ago

Since the service is already read-only, you don't have the option of using it against the recommendation, and so no this is not merely a deprecation.

chrismorgan4• 4 years ago

Take both notices together and you can see that they’re clearly using the wrong sense of the word deprecate. From the January notice:

Existing URLs will continue to be accessible, but we encourage using one of the many URL shortening services that are available, instead of git.io, as we will be deprecating the tool in the future.

Semantically, that was clearly a deprecation of the service: it keeps working, but they discourage its use as it will be discontinued in the future. (It was also notice of shutdown of the write parts of the service.)

It is not reasonable to consider today’s notice to be a deprecation (interpreting that as a change in status).

There is no requirement a deprecated service still works.

This is flatly wrong. The agreed meaning of the word “deprecate” requires that it still works. See https://en.wikipedia.org/wiki/Deprecation for a good overview of the term’s proper usage and accepted meaning.

mgdlbp3• 4 years ago

The problems with url shorteners https://news.ycombinator.com/item?id=545565 – 2009-04 (56 comments)

URL Shorteners – the herpes of the web https://news.ycombinator.com/item?id=570041 – 2009-04 (17 comments)

Url Shorteners: Destroying the Web Since 2002 https://news.ycombinator.com/item?id=660087 – 2009-06 (57 comments)

URL Shorteners are evil, here's one to prove it. https://news.ycombinator.com/item?id=904941 – 2009-10 (57 comments) – ironically dead

Link shorteners hurt the user experience and destroy the Web https://news.ycombinator.com/item?id=7803290 – 2014-05 (89 comments) – dead

The URL shortener situation is out of control https://news.ycombinator.com/item?id=7836626 – 2014-06 (78 comments)

URL shorteners set ad tracking cookies https://news.ycombinator.com/item?id=25624112 – 2021-01 (207 comments)

Link shorteners: the long and short of why you shouldn’t use them https://news.ycombinator.com/item?id=27462261 – 2021-06 (145 comments)

rectang• 4 years ago

Eventually, all domains expire. It's not just url shorteners.

You can't count on anything on the web lasting. You can't count on anything disappearing either.

When you want the web to be ephemeral, "the internet never forgets".

When you want the web to be permanent, the site you remember will be abandoned and lost.

jraph2• 4 years ago

Yes, and everybody dies one day.

But you don't need to double the problem by making a link rely on two domains and shortening its life.

What's more, if you have the complete original URL, you might be able to use an archive service that might have taken a snapshot, or at least try to guess what was behind the link by looking at it. Shortened URLs are usually inscrutable.

slabity• 4 years ago

The problem isn't that web sites or domains expire. It's that adding another redirection like URL shorteners makes another point of failure. And URL shorteners create points of failure across many points. It also makes it more difficult for archival services to keep accurate links to those expired sites as it then needs to keep track of every shortener on every website.

ksec• 4 years ago

You can't count on anything on the web lasting.

Can I theoretically buy a Domain name outright? Or for 99 years?

joshu• 4 years ago

hey, that first link is me. called it!

johtso2• 4 years ago

Shout out to the people over at URLTeam trying to fight the link-rot..

https://wiki.archiveteam.org/index.php/URLTeam

https://tracker.archiveteam.org:1338/

hardwaresofton• 4 years ago

Uhhh… how close to being herpes is a service that locks like being authentication[0].

I think of my service more like security but it does shorten…

[0] https://waaard.con

johndough• 4 years ago

And just like that, several hundred scientific papers which used git.io links become incorrect https://scholar.google.com/scholar?hl=en&q=git.io

Changing the content of papers after they have been published is usually impossible or at least extremely difficult, depending on the publisher.

asvitkine• 4 years ago

I wonder if anyone is working on an archive?

xucheng2• 4 years ago

It is unlikely because it is very difficult and maybe illegal to scrape research papers. See https://en.wikipedia.org/wiki/Aaron_Swartz for example.

johtso2• 4 years ago

If anyone is it would probably be the people over at ArchiveTeam / URLTeam: https://wiki.archiveteam.org/ https://wiki.archiveteam.org/index.php/URLTeam

ktpsns• 4 years ago

Digital Object Identifiers (DOI) are nowadays the academia variant of URLs. DOIs are somewhat similar to URNs, they don't resolve directly somewhere in the web but are more a kind of identifier. There are various tools for resolving, see for instance https://www.doi.org/tools.html

Platforms such as https://zenodo.org/ allow for uploading digital artifacts such as publication attachments, supplementary codes or measurement/survey data and assigning them permanently with a DOI.

Zenodo may go down, but maybe some hard disk survives and resolving that DOIs will be possible at some future web system. DOIS are built to last!

dataflow2• 4 years ago

I'm confused, what's the relationship between DOIs and git.io? Are you suggesting people should be using DOIs to link to source code from within papers?

the_biot2• 4 years ago

The git.io link in at least the first paper that comes up on your search (https://git.io/sosr15-int-demo) appears to have been archived by archive.org, which shows the redirection and then follows it to the archived version of the final github page.

I don't know how common it is for these links to have been caught by the archive, but potentially all is not lost.

eythian• 4 years ago

There is an archiveteam project that scrapes URL shorteners, so hopefully more than one might expect.

oefrha2• 4 years ago

Glad I made the decision to use my own 5-character domain for URL shortening years ago. Anyone can write a simple URL shortening service in less than half an hour, and you gain flexibility and peace of mind with that little bit of effort.

Still, losing all git.io links hurt. I’m certain I have a few old projects with issue explanations, download links, etc. based on git.io. This is handled so poorly it’s ridiculous.

oxguy3• 4 years ago

Guess I'll finally have to bookmark play2048.co, if git.io/2048 is gonna stop working.

0x0000000• 4 years ago

Discussion from the January announcement: https://news.ycombinator.com/item?id=30024993 - 56 comments

noway421• 4 years ago

As an owner of http://git.io/way and https://git.io/no it's a good thing I noticed this on hackernews front page. Otherwise I would've never known! Just changed all of my git.io links where I could find them. I wish they would send out emails for this, but as I remember git.io is an anonymous service.

dataflow2• 4 years ago

While I'm a little annoyed by this (it seemed unlikely to me that GitHub would shut it down, so I actually used it), I can live with it. The "was only lightly documented" comment is pretty unnecessary and just adds insult to injury though. What's that supposed to mean? It feels like such an "it's kinda your fault for putting too much faith in us" insinuation. GitHub literally blogged about the feature [1], did they expect people not to use it because it wasn't "heavily" documented? Should their users ignore their blogs from now on, because apparently it's an irresponsible thing to take their blogs at face value?

Oh, and I don't think they've sent anyone any notifications about this, like the repo owners. Not sure how people are supposed to find out; are all users expected to stay up to date with GitHub's blog... which GitHub is telling them not to trust?

[1] https://github.blog/2011-11-10-git-io-github-url-shortener/

math-dev• 4 years ago

All good points

larusso• 4 years ago

I’m in general not a fan of sunset ting services which are part of greater infrastructure. The demise of jcenter for instance is still hunting me because of cache misses etc. And I had the same thoughts about the documentation comment. For me this means that GitHub has put itself in the long lines of service companies who have no issues with pulling the plugs (because this is mostly the cheapest solution) of services they don’t want to maintain for whatever reason.

ThrashBeard• 4 years ago

The way I understood "was only lightly documented" was they were blaming themselves like "we didn't put much work into it and didn't document it very well".

hjkl0• 4 years ago

As someone without a leg in this race, I found the added context of “lightly documented” useful. It does help tell the story

rjmunro• 4 years ago

"https://git.io/" seems to occur about 200,000 times in source code: https://github.com/search?q=%22https%3A%2F%2Fgit.io%22&type=...

It would be good to write a script to fetch all of those and log their destinations to a CSV file and put that online somewhere. You could even make PRs to all of those projects replacing links with un-shortened versions.

I hope github will replace the redirects with a holding page linking where they used to redirect to, rather than just delete them. That way people can report the broken links to the original site and still get to the destination they were intending.

soco• 4 years ago

Given how often I get the "this is not the page you're looking for" I can safely assume they won't care this time either.

snthd• 4 years ago

https://wiki.archiveteam.org/index.php?title=URLTeam

romantomjak• 4 years ago

This is why you should never use url shorteners for publicly addressable content. Using url shorteners contributes to ‘link rot’ and after the domain expires or the service reaches its end of life the link is broken and cannot be resolved anymore.

imo, it’s fine for linking to ephemeral content such as submission forms or anything that will not make sense after a certain time. Do not use it for articles and other content, because it will make the resource inaccessible after the service is no longer operational.

jacobmischka• 4 years ago

Off topic, but I have really grown to despise the phrase "out of an abundance of caution". It's grown so popular during the pandemic when people exercise the absolute bare minimum amount of caution.

smegsicle• 4 years ago

as if 'can't be too careful' is an excuse to forgo discernment

henvic• 4 years ago

Why don't them just start returning the redirection link as a text (so if you want to follow, you must copy & paste), and call it a day?

donohoe• 4 years ago

Great - but seems like very short notice. Just 4 days? Maybe 4 weeks. We're going to see a lot of broken links across the web.

bsuvc• 4 years ago

This is not a developer-friendly decision.

Why can't they leave it working for existing URLs at least?

A quick search shows 704,000 code results containing git.io.

https://github.com/search?q=git.io&type=code

Edit: actually it is more than 704k, much more it seems.

pc86• 4 years ago

They mention security but don't expand on that, I wish they would have.

computerfriend• 4 years ago

GitHub has been quite thoughtful about its deprecation timelines before, e.g. with long notice periods and brownouts. They're handling this quite badly.

Personally I don't see why they would care that it is used to shorten links to malicious redirects or whatever. But given that they do, the easy fix is to drop the github.io domain but keep the github.com domain. And in the interest of letting people update their URLs, returning the redirect URL as a response body instead of a 302.

beliu2• 4 years ago

Here is a list of open source projects that should update their git.io URLs, ranked in order of popularity: https://sourcegraph.com/search?q=context:global+https://git....

beliu2• 4 years ago

Sourcegraph CTO here. Does anyone know someone at GitHub or Microsoft we could get in touch with to take over maintenance of git.io? There are hundreds of thousands of references in open source, blog posts, and academic papers that will 404 if git.io is taken down. Sourcegraph would be happy to take over maintenance to preserve these links.

untitaker_• 4 years ago

Playing the ball back: I was trying to export all git.io links through your sourcegraph code search, but the CSV export doesn't work for those purposes (it times out). Is there a chance you can publish this dataset now such that crawling git.io is easier?

EDIT: https://twitter.com/untitaker/status/1519034010978160641

Git.io deprecation

Related Stories