Linux Kernel Git Repositories Add 2-Factor Authentication 49
LibbyMC writes For a few years now Linux kernel developers have followed a fairly strict authentication policy for those who commit directly to the git repositories housing the Linux kernel. Each is issued their own ssh private key, which then becomes the sole way for them to push code changes to the git repositories hosted at kernel.org. While using ssh keys is much more secure than just passwords, there are still a number of ways for ssh private keys to fall into malicious hands. So they've further tightened access requirements with two-factor authentication using yubikeys.
Oh no. (Score:4, Funny)
Someone might commit code to our open source project. We can't have that.
Re: (Score:1)
Yes, malicious actors. The Linux kernel repos have never been a free-for-all.
Re:Oh no. (Score:5, Funny)
Okay, so once again I have to be reminded that no one is allowed to joke about the Linux kernel, because the distros are responsible for packaging a sense of humor.
Re: (Score:2, Funny)
As long as we're being humorless assholes:
Jokes are defined by the intention of humor. Lots of things are funny that aren't jokes, like, say, if you died, it'd be hilarious. Lots of things are jokes that fail at being funny: see the complete works of Carlos Mencia.
Re: (Score:1)
Re: (Score:2)
No moms, please.
http://youtu.be/KzelrlH_pjQ [youtu.be]
Re: (Score:1)
Look, use a dictionary next time you want to talk about definitions. Your own are just wrong.
Re: (Score:2)
Ain't he that four-star prospect whose tearing up triple-A in the Cubs farm system? I saw him play with Iowa and he's a terrific-looking second baseman who can hit for power.
I didn't know he's a comedian too.
Re: (Score:2)
As long as we're being humorless assholes: Jokes are defined by the intention of humor. Lots of things are funny that aren't jokes, like, say, if you died, it'd be hilarious. Lots of things are jokes that fail at being funny: see the complete works of Joe Rogan.
FTFY
Re: (Score:1)
On common dumb phrase in Unix is "Everything is a file." How can you say a piece of hardware is like a file on a disk, when it obviously has various features? That's the whole point, ignore, ignore, ignore the features to utter terseness in the interface, beat it down with a club into a uniform, system wide dumb mode first, then add the features and complexities later, but preserve the uniform text interface in everything, don't customize into a myriad of unique and non-compliant standards. If I remember ri
Re: (Score:1)
Also, computing already follows similar simplicity at the core as life does. Everything in life is A C T G, and everything in computing is 0,1. But we're dealing with the complexity issues arising at higher levels, than 0,1. In particular, the closer you are to 0,1 the simpler and more straight forward, the more "Unix" the procedures should be, and the farther away you are, the more variety, the greater flamboyance, the greater exuberance of rococo, such as menu options, flamboyant colors, and richness of d
Re: (Score:1)
Yeah, I forgot the part where the copperheads advance to 9dans, and destroy the system from within. The situation then becomes similar to the French Revolution, where the 30kyu peasantry rebels against the 9dan monarch and 5 dan nobility, and guillotine their heads. If a 9d copperhead is caught, after getting away with things for a long time, just like the nobles/kings could in France, but eventually there'd be massive flame-wars about it, in a rebellion style, where it becomes obvious you have to roll out
Re: (Score:1)
I just had this idea that in programming, Roman numerals might be more efficient than Arabic/Indian, but only when you can guarantee gaps, or granularity. Such as when dealing with bytes, each being 8bits, or 2^8=256, and wasting space, granularity when you only need to represent 17, which can be done in 2^5=32, but not in 2^4=16. Similar things are FAT cluster sizes, that waste space on clustering, in the name of Roman numeral style efficiency. In this sense, in roman numerals you only represent the centur
Re: (Score:1)
I just figured that one out, or more like I just got the divine revelation, even though "they" teased me with the same thing before, in 2009, but mind controlled me not to realize it.
Re: (Score:1)
Correction: It's not 1!+2!+3!=4!-1, but 1*1!+2*2!+3*3!=4!-1, as in 1*1+2*2+3*6=1+4+18=23, which is 24-1. My memory failed me there, but the point is there is a different way to represent digits that gets full granularity of integers without gaps in it, other than just the geometric progression Indian/Arabic/Mayan method.
Re: (Score:1)
It's more complicated than what I made it sound, because each position has a variable base as opposed to a fixed base in geometric progression, b, so you could in theory reserve more room than a base for higher numbers. The situation is similar to decimal hex, or binary coded decimal, where your base is F, but you only go up to 9, and lose the available representation space between 10 and 16. With a fixed base, factoradic loses the representation space available for each digit, on the other hand it takes up
Re: (Score:1)
Now I went to the Wikipedia page, and it says you're allowed digits only up to the position number at each position in the factoradic, such as
Radix 8 7 6 5 4 3 2 1
Place val 7! 6! 5! 4! 3! 2! 1! 0!
Plcv decl 5040 720 120 24 6 2 1 1
Highest 7 6 5 4 3 2 1 0
digit allowed
I thought since both 0! and 1! equal 1, you start from 1, not 0, and also that you could go to 5039 in digits at 7!, right before you hit 5040, in a va
Re: (Score:1)
Well the important thing is, that when doing 168 pin RAM sticks, and looking at the pipe of data coming through them, on each line, if they come through in say decimal representation, with 10 voltage values each, then you can get 10^168-1 values out of it (like you can 0 to 9999 from a 4 digit bicycle lock, not 10,000, or 0-255 from 8 bits, not 256, but with factoradic representation with variable base, the highest allowed digit on the 168th line is 168, as in 1,2,3..A,B,C (you run out after 10 digits plus
Re: (Score:1)
How about if you tried to apply Roman numerals instead of Indian/Arabic binary representation for each digit? Would it get terser, as an overall sum, where you could surpass the Indian/Arabic fixed base geometric progression with the factoradic variable base progression? After all, you only need one character to represent 1000, M, from a lookup table, so you have M, D, C, L, X, V, I, or 7 different values, and a maximum craziness of MMMDCCCLXXXVIII, or 3888 requiring 15 digits within its usual representatio
Re: (Score:1)
By the way I found illustrative examples of what Unix should be like, on the pussy analogy:
First of all, here is a rococo-pussy (this is not what you want Unix to look like):
http://nudes13.hegre-art.com/h... [hegre-art.com]
It's dark, mysterious, full of features, difficult to debug.
Here it is for closer inspection, under the hood, it's still dark, mysterious and difficult to find the fleas in it:
http://nudes13.hegre-art.com/h... [hegre-art.com]
Compared the above to this unix-pussy:
http://conten [pureandsexy.org]
Re: (Score:2)
Yep, exactly. That's how I won a free meth lab.
Re: (Score:2)
Did they have a problem with that? Or are they operating on the possibility, instead? Do you have a third source of information?
Because the summary isn't clear, and the article is a how-to.
Re: (Score:2)
Well, malware injection to the linux kernel isn't a mere possibility. The incident that happened back in late 2003 comes to mind.
Re:Malware (Score:5, Informative)
I don't think you are intentionally trying to misrepresent the facts, but before others take the misrepresentation of the facts and run with it ...
I think you are confusing a failed attempt with a successful injection. The checks and balances in place stopped it sans two-factor auth. This just makes it even more unlikely.
Re: (Score:2)
Agreed, the path that was taken for that attempt wouldn't have worked. However, if someone had been able to compromise the credentials that would authorize a check in to the main repository, it most definitely would have worked. Adding in two factor authentication just makes it that much harder.
Yubikeys? (Score:2)
You mean I can no longer use my Battle.net Authenticator for my commits?
Re: (Score:2)
Finally as secure as MMO games (Score:5, Funny)
Finally the Linux kernel which runs almost the entire Internet is as secure as my MMORPG accounts. About time. :P
Re:How does it work without a clock? (Score:5, Informative)
A Yubikey token looks like 'ficrtvulktgnerhddigbhcudufurijghfcckvchhjfli' and is a modhex (16 chars picked for being the same across charsets) and contains the following:
1) A public ID to identify the key
2) AES128 encrypted 128 bits containing the following:
a. Secret ID
b. Insertion counter (how many times its been plugged into a computer)
c. Token counter (within one insertion)
d. Timestamp (A counter counting the time since the token was inserted into the computer)
e. Random number
f. Checksum of the above
Their website [yubico.com] has full specifications and documentation.
Re:How does it work without a clock? (Score:4, Informative)
Re:How does it work without a clock? (Score:4, Interesting)
Well, you could have answered your own question by simply using google to look up Yubikey and reading a bit. But to give you a partial answer, the token generates an AES encrypted value and passes that value to the server for authentication. During authentication, the server decrypts the value. (the shared secret between the token and the server is the AES encryption key). The decrypted value includes a counter. And if the counter isn't greater than the previously used counter, the authentication attempt is invalid. So if you were to hit the button 100 times and record those codes, you could authenticate using any of those codes, but as soon as I hit the button and authenticated using the resulting code, all of the codes you recorded would become instantly invalid.
Thumbs up (Score:2)
Let's see:
- Authenticated kernel source.
- Checksummed distro ISO.
- Eeprom subverted thumb drive.
keys are not issued to someone they are generated (Score:4, Insightful)
The point is that only *you* should ever have access to the private key, having someone else generate it (as is suggested by the wording in this article) would be very unusual, as you would not want to use this key for anything else, and someone else would have your private key for no good reason. Someone could even potentially use this key to fake your identity in commits.
The problematic wording is here: "Each is issued their own ssh private key".
Re: (Score:2)
Re: (Score:2)
I still fail to see the benefit of generating the key on the kernel.org system and sending it PGP encrypted. Why not just generate yourself and send it to the kernel.org administrators PGP encrypted instead? (as per the reply below, using 3rd party private keys is bad practice)
Re: (Score:2)