If a script sees "ABC123" in a code commit, that's meaningless. If you see "secret-token:ABC123", now you can fail the commit with an error message: "Secret token detected in public commit, aborting."
> An informational RFC can be nearly anything from April 1 jokes to widely recognized essential RFCs like Domain Name System Structure and Delegation (RFC 1591). Some informational RFCs formed the FYI sub-series.
* Helps in migrations, especially complex ones where you split up entity types.
* Identities what tokens are so people can look them up if they see them in logs.
* Polymorphic relationships can delegate to the appropriate owning service easily without additional bookkeeping.
You can also encode other stuff in the token entropy, too, such as the author DC/region for active-active setups where you need to forward the request to the source of truth in the brief window where the other regions don't know about it yet.
Shout out and kudos to whomever brought that up
e.g. in powershell on Windows, Ctrl+Backspace deletes the word part, but in cmd shell, Ctrl+Backspace deletes until whitespace. The keybindings to delete word also vary on Windows vs MacOS (Alt+Backspace deletes a word on mac, but deletes the whole line on Windows. Windows uses Ctrl+Backspace for that).
I was also confused since by-default Emacs doesn't treat `_` as a word character.
This is just a little bit misleading. Base64 isn’t a single neat and tidy thing: there are several alternatives for the encoding characters 62 and 63, padding, line break behaviour and one or two more things; see https://en.wikipedia.org/wiki/Base64#Variants_summary_table. When you’re talking about Base64 on the web, you’ll very commonly be talking about base64url, the URL- and filename-safe variant, rather than what’s most commonly called base64 and typically the default. But base64url is in widespread use, and has _ as character 63.
Also “randomly generated strings like SHAs” aren’t typically doing Base64 anyway,but rather hexadecimal encoding.
I think these new formats are nice, but don’t care give how hard to use their token scheme is. Just some mention of other stuff coming would be nice.
The problem I have is I’m not even sure if GitHub recognizes this as a problem (I have to grant access to every repo I can access to every script) and it’s been broken for years. Would be nice to know what they’re working on.
It seems to me that its a PM centric process i.e. lots of end-user features rather than fixing the behind the scenes parts that are poorly designed and/or broken.
We tried to workaround the inadequate token support by using their Terraform module for automation. Only for it to delete our repos losing years of issues because of a bug where renaming = deleting (3 year old issue that has never been prioritised).
b) Talking about fundamental flaws in their token implementation seems relevant in a discussion about their token implementation.
c) Public discussions about flaws are often the best way to educate others and make the company aware of them.
If you want to take advantage of Environments for example then you need to pay for the Enterprise license which means every account is another $21/month. That adds up for individual and startup use.
I am actually confused why we can't just have tokens assigned to organisations and not users.
But there’s also later more detailed guidance:
”One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).”
Yet this is something I, and many others, do because we don't want to mix business with pleasure. In fact I absolutely refuse to do so because of security reasons.
In practice this is mostly so github has a reason to misuses like bots which might not be caught by the anti-spam measure.
They do mind a bit but not too much, and you can get help from support having literally stated that you have multiple accounts. For instance if you're testing an extension or integration with github, and there are specific interactions between different users… you kinda need different users to test it. And mocking github may not be sufficient.
The work account is strictly to communicate with/provide patches back to upstream projects.
I have multiple personal accounts on Github. One for each employer I have worked at in the past couple of years, and my personal account that is tied to my own identity and is used for my personal time projects/open source work that is not tied to $work.
I'm definitely kidding, but unless there is more in there TOS (which I don't intend to read) I don't see why this wouldn't be a workable loophole
Doesn't remove their need to implement a more reasonable way of scoping tokens, though.
Everything from Security, Actions, Containers, Packages, Terraform, JIRA Integration etc is either completely broken or has major outstanding issues that haven't been fixed for years.
That said, GitLab has its fair share of problems too. GitHub UI is way better, community/discussion features are better, and forking/public collaboration workflow is better.
I'm glad there are two big players in the space, though; GitLab really lit a fire under GitHub to finally get them to start pushing new features.
You could add a prefix to a jwt. That would make it a token that contains a jwt.
I don't think the tiny prefix is what they want to obscure. So it wouldn't go against the design of JWT to add one.
I would do it. I don't see any issues with it.
It would be something like:
If you wanted to be able to double click to copy and paste, which I don't think is a huge usability improvement, you could replace the . with _, and I think a lot of devs would be able to figure out that it's a representation of a JWT.
But JWTs are generally somewhat ephemeral (they expire) so you’re fairly unlikely to commit one into a source repo in a way that could do actual damage...
Then you can just strip the prefix before parsing. Which means don't need to worry about checksumming or entropy and you have the ability to embed large amounts of data as well as plenty of client support and libraries.
Would be curious if this implementation is somehow more performant.
The subject doesn't need to be a user ID, and it sounds like they don't want that. It could be a session ID.
The more interesting side to me is the benefit to humans, from the prefix technique.
I loved the use of underscore and the "it'll reliably double click"
I liked that they looked to other companies out in the sold and acknowledged that they're learning from others.
I didn't know what to expect when I opened the link, but I'm glad I read it!
If you use a service you’re worried the change may break I’d recommend minting a new token and trying it, perhaps on a new account on that service, before revoking your old one.
(We do plan to increase the length of our tokens in future, but not before July 2021 at the earliest.)
It's possible that Git Tower does some local validation that might complain, but I think they are in the same set of characters.
You could always write a crack for the local validation, too.