Linux Kernel Git Repositories Add 2-Factor Authentication

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.

Comments

Oh no.

[i kan reed]

Someone might commit code to our open source project. We can't have that.

Re:Oh no.

[Anonymous Coward]

Yes, malicious actors. The Linux kernel repos have never been a free-for-all.

Re:Oh no.

[i kan reed]

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:Oh no.

[i kan reed]

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:Oh no.

[PopeRatzo]

Carlos Mencia

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:Oh no.

[PopeRatzo]

No moms, please.

http://youtu.be/KzelrlH_pjQ

Re:Oh no.

[ArhcAngel]

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:Oh no.

[sillybilly]

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 right, in later versions of Linux I had issues treating items under /dev and especially /proc as regular files, they forgot about implementing the core principles of behavior. But I don't claim to understand the reasoning behind it, which may be reasonable. It is still nice to be able to dd if=/dev/cdrom of=./file.iso , from hardware. You can't do that in windows, or dos, from simple command line, but in Unix everything is a file, that you can read from and possibly write to, precious data. That's what a computer is for: helping me massage my data. And in that, I'd like to reserve my 1 TB portable disk for pictures of butterflies, or videos, and would prefer if the code that got everything accomplished stayed under 150KB. I realize that's not possible, but what's happening in today's computing environment, when it comes to multi megabyte code size that massages the 1TB data, is simply a joke. There was this saying back in the day, at IBM, that 1 MB should be enough for everyone. And by that I think they meant for code size, not data, as I wish to store months and months worth of compressed videos, and I would have no problem with code that could massage it to all my needs, AND stay under that 1MB. If nothing else, self generated code from simple rules, could accomplish starting from an under 1MB seed. However self generated code brings about the danger of mutations and AI. And AI, along the movie of "Screamers" from 1996, is the biggest threat humanity is facing today, bigger than biotech or nuclear holocaust, because you can run away from those two into outer space, but not from an AI cleverer than you set out to chase you and hunt you down. That movie might seem funny at first, but it's really not funny. Everyone who programs computers, and automates designs, similar to how life automates mutations as new Monte-Carlo designs and selection from them, should always keep that movie in the back of their minds. And in this sense they should set limits on computing power available in laptops and desktops, and the relentless drive for more supercomputing, and more bloated software like KDE4 and higher, when even KDE3's biggest problem is codesize and performance, compared to windows. For instance, when copying files in Konqueror, Windows 2000 ran circles around KDE 3, but not in command prompt of course. So how do I get user friendliness out of Unix, and performance at the same time? All I see is bloat bloat bloat these days, that refuses to run on older hardware, when in my mind progress in software science would mean increased speed even on older hardware, because, as far as the features go, I'm not seeing any tremendous advances, it's all just the same thing, with a different face slapped on it, 10x slower than 10 years ago. Like MS Office 97 can accomplish pretty much everything that Office 2010 can, and even do so more efficiently, plus in a way I find awkward because I got used to the old ways, so why should I get used to the new ones when I get no benefit at all from it. In fact I have to click twice to get to a menu item that used to take one click on the tool bar.. Similar gripes of I used to be able to do this and that in Linux, and all of a sudden they took it away, and got something "better"? Really? That much better that it's worth constantly switching ways of doing things? How are businesses to rely on that kind of Unix, that won't last the full carrier of 30 years of one of their freshly hired college grads? They never get the chance to get expert at it, or create software

Re:Oh no.

[sillybilly]

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 decoration. For instance, a colorful lizard is flamboyant at the user interface, appearance to the external world, but adheres to the principles of all eukaryotes, in how it functions closer to the ACTG level. Similarly, KDE should be flamboyant at the user interface level, or VB Classic/VBA Macros can be flamboyant in what all is implemented in them, at the user interface level, but simple at the vbrun60.dll level. All eukaryotes adhere to the principles of having a cellular unit with a nucleus, mitochondria, etc, and in this trees and grass and lizards and you and I are similar. It does not mean that the principle is a correct one, for instance a totally mindless and dumb prokaryote might evolve that does not have a nucleus, and chew and digest off Alien's face, digest up all trees, all other lifeforms, and in a sense, prevail in the competition to survive by becoming the new top predator. Being a eukaryote means you believe that it's efficient, and stick to it, but that belief is not a guarantee, and you can have raging debates about it, or even might have some human cells where it might make economic sense to be prokaryote instead of eukaryote for some of the specialized cells, but in the meantime everyone sticks to this guiding principle, not because it's correct, or good, but because it is what it is. Similarly, in an aerobic, oxygen atmosphere, for multicellular life other than bugs, which have no blood but a tracheal lung system that penetrates all the way to individual cells and brings oxygen directly, so for multicellular lifeforms that do have blood, hemoglobin based on iron has arisen as the dominant and only standard, being the most efficient life could come up with. There are exceptions with blue blooded molluscs, like octopi, which sometimes live in depths of great oxygen depravation, and at those oxygen concentrations the copper based blue blood is more efficient, but all fish, all reptiles, all birds and mammals have red blood. Red blood might be complex in an of itself, but it became a standard everyone follows because we don't know anything more efficient. In the biotech future there might be artificial synthesis of something more efficient, and human derived artificial people based on them, such as green blood or orange blood, who can win olympics, but for now life is stuck at hemoglobin, which is both complex and efficient, and maximum state of the art. Similarly all vision systems are based on a vitamin A derived molecule, already at the limits of theoretical efficiency, as in 4 photons able to trigger a visual response in the brain, but there might be inventions where a single photon does it - and it may not be the molecule itself, because, in theory, that changes conformation from a single photon, but the overhead circuitry, which, may be damping out and filtering single photon detection on purpose - but once you got single photon detection, you know you can't get any better than that, maybe less expensive molecules to be used. In number systems around the world we use the positional Hindu/Arabic system as opposed to the Roman, and we have nothing better so far, so it's a universal standard.

(By the way the positional system is encoded instinctively into words such as 10, 20, 30, 40, and such things as 31,32, 33,... then 41, 42, 43, so it's weird that the Greeks and Romans could not come up with 4something to represent 40, with zero. But the french have quatre vingt huit for 88, literally meaning 4-20-8, as in 4x20+8, so some number systems don't follow the simple rules that would yield

Re:Oh no.

[sillybilly]

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 the guillotine and have some heads roll. Of course this situation can be abused too, to where someone like Linus or Alan Cox could be ousted, and then it's up in the air whether the rebels are paid by Microsoft, to kill Linux, or there is a true problem with a rotten leadership. Of course it's hard to see Linus intentionally damage Linux, on the other hand he does look like he's the cousin of Bill Gates, and he lives in Oregon too, not too far. So ya never know these things. That's right, I pick on everyone equally without exception, nobody is safe from the terror of my words, even Linus. But if it bothers you, you can ignore, and get on with your life. Nobody forces you to read all this.

Re:Oh no.

[sillybilly]

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 centuries by a few characters, such as MM for 2000, MCM for 1900, MDCCC for 1800, MDCC 1700, MD1500, MCD 1400, MCCC for 1300, ..etc. and MC 1100, M 1000, CM 900, DCCC 800, etc. You could cut this down to 3 digits, to lose even more granularity, but your granularity is maximum near the KB or MB levels, right near the cluster size, and instead have options of MM, MCM, MDC, MD, MCD, MC, M, CM, DC, D, CD, which work near the 500 level, and some granularity nearby it, but are inefficient away from the 500 cluster level. If you could get more terse like that, in expression, as in military units one would be M, other D, other D, other L, other X, then V, and the individual soldier, I, so with cutting down to one character or two characters instead of 4 characters required by Indian/Arabic, you could get some bandwidth, terseness of conveyed information, and less parallel lines to carry that bandwidth, to memory for instance. This is illustrated in datatypes, which also lose granularity, but are the equivalents of M, D, C, L, X, V, I, in most typed programming languages. So I'm just adding this thought of how the Roman numerals are stupid to do math calculations, but in certain circumstances they make sense, such as counting available military units.

I just got curious what the letter for 5000 would be, so I looked it up in Wikipedia. There is no such number, and the ancient system is only good for 3999, and there are two methods to get higher numbers, one draw a bar above a number meaning it's multiplied by M, or 1000, so you can represent up to 3,999,000 or almost 4,000,000, and most millionaires could not count their money like that, but then you can keep adding more lines to keep getting higher multiples. The other method, more complicated, but descended from Etruscan tradition that Roman numerals came from, cannot be printed here, because Slashdot eats the funky backward C characters, and you have to read it at http://en.wikipedia.org/wiki/R...

So these are the two known methods of number representation, there is also an option for factoradic, with full granularity, where 1!+2!+3!+...+n!=(n+1)!-1, n!=1x2x3..xn, 1!=1, 2!=2, 3!=1x2x3=6, 4!=1x2x3x4=24, 5!=120, 6!=720, etc, but it's not more efficient than Arabic/Indian, because that uses the rule applied to geometric progressions, of b^0+b^1+b^2+b^3+..+b^n=b^(n+1)-1, and as long as you have your highest base, b, there is no reason at each positional representation not to go all the way up to that highest point. For instance when we say 3528 we mean 8x10^0+2x10^1+5x10^2+3x10^3=8x1+2x10+5x100+3x1000=8+20+500+3000=3528. In factoradic representation you'd only be able to go up to n! at each position, not the full base, such as 3528 being 8x1!+2x2!+5x3!+3x4!=8x1+2x2+5x6+3x24=8+4+30+72=114, a very slow and inefficient way to store numbers, because you could have used each position to store at the highest base available, such as 10 base, implicitly understood, and get much better storage capacity while you still get the full granularity of representation, for each natural number, unlike with chopped roman numerals, or even scientific notation for Indian/Arabic numbers, which we call floating point representation, which is full of holes and cannot represent every single integer to its highest limits. With factoradic you can only go up to n! times the decimal base at each position, while with Indian/Arabic you can go up to base^position, and only for very high numbers do factorials surp

Re:Oh no.

[sillybilly]

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:Oh no.

[sillybilly]

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 a fixed amount of memory per digit, so there is various mixes and matches between fixed base geometric, fixed base factoradic, and variable base factoradic, and variable base factoradic might be the most efficient with full granularity encompassing all natural numbers in a range for huge numbers, while fixed based factoradic might be more efficient for intermediate numbers, and fixed base geometric series Indian/Arabic for small numbers.

Re:Oh no.

[sillybilly]

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 variable base, just like you can go up to 9, right before you hit 10, in digits in a fixed base geometric progression. Or to 23 in digits right before you hit 4!., as in 1,2,3,4,5,6,7,8,9,A,B,C,D,E,F(15 of hexa), G, H, I, J,K(icosa),L,M,N(23, of tricosa), so you could have a number like L511 meaning Lx4!+5x3!+1x2!+1x1!. Something is not right here, because the 1x2! and 1x1! only allow 1 as the highest digits, hmm. So anyway the number then is 23x24+5x6+1x2+1x1=552+30+2+1=585, which is much higher than the next up number, 5!=120, so you'd end up with multiple representations for the same number above 121, plus you'd need variable storage space, as you need 120 digits by the next round, and the 26 letters of the alphabet are not enough, so it may not be better after all. The important thing is to try, and keep trying for better. And I'm not smart enough to figure all this out anyway. In any case you can't go up to 9999 in digits when you represent 10000, for the second position at 1x000, but only to 9, or doing so does not cut down on storage costs, by the time you're done representing those digits.

Re:Oh no.

[sillybilly]

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 26 Roman letters, so you go alpha, beta, gamma, etc, pile on everything you know til you get a 168 base digit), so you'd have a number like gamma x 168!+L x 167!+... +3 x 3! + 2x2! + 1x1!, according to their rules in Wikipedia, which is still fully granular, but much huger number, as 168! > 10^168 by a whole lot, and the situation becomes even more stark when you compare 168! > 2^168, as in binary, the only issue being that each digit must be represented by 168 possible digits, which in binary takes up 256 or 8 bits, with room to spare above 168 to 255, so you divide 168/8=21, so you can really only go up to 21!, which may still be bigger than 10^168, but still get full granularity of integers. But it's not, as 21! = 5.11x10^19 according to google, which is a whole lot less than 2^168-1= 3.74x10^50. So at 168 pins the variable base factoradic representation is not more efficient than the fixed based Indian/Arabic geometric progression. Hmm.

But that gives me the Idea, that you don't have to divide 168 by 8, as for the initial digits you only need less room, and 8 bits are wasted, so you need for 1, 2,3,4,5,6,7,8,9,10,11.... etc 1/1 bit, 2/2 bits, 2/3 , 3/4, 3/5, 3/6 ,3/7, 4/8,4/9,4/10,4/11,4/12,4/13,4/4/14,4/15, 5/16,5/17,5/18,5/19,5/20,5/21,5/22,5/23,5/24.5/25,5/26,5/27,5/28,5/29,5/30,5/31,6/32,6/33,6/34,etc, and I'm too lazy to calculate how many you need, but if you use binary geometric progression encoding of the factoradic digits, you only need 7 digits to get the numbers under 127, 6 under 64, 5 under 32, 4 under 16, 3 under 8, 2 under 4 and 1 under 2, so (168-127)x8+(127-63)x7+(63-31)x6+ etc = (1097 I got at convertit.com, but I'm stupid because that's not how many digits you get, but instead =) 41/8+64/7+32/6+16/5+8/4+4/3+2/2+1/1 = 1+2*2+3*4+4*8+5*16+6*32 etc, as far as you can go, to stay under 168 available pins on the RAM stick, I make a Microsoft Works spreadsheet that came with my HP Mini Recovery DVD, that looks like this

n 2^n (n+1)*2^n Partial Sum
0 1 1 1
1 2 4 5
2 4 12 17
3 8 32 49
4 16 80 129
5 32 192 321

So it shows that 129 is the highest number under 168, so you need 129 pin to carry all factoradic variable base digits up to the 4 digit ones, now I'm confused, so let's go back, you need 1+2+2+3+3+3+3+4+4+4+4+4+4 eight times, etc.. so I'm going back to make a different spreadsheet,

Numeral Pins Subtotal
1 1 1
2 2 3
3 2 5
4 3 8
5 3 11
6 3 14
7 3 17
8 4 21
9 4 25
10 4 29
11 4 33
12 4 37
13 4 41
14 4 45
15 4 49
16 5 54
17 5 59
18 5 64
19 5 69
20 5 74
21 5 79
22 5 84
23 5 89
24 5 94
25 5 99
26 5 104
27 5 109
28 5 114
29 5 119
30 5 124
31 5 129
32 6 135
33 6 141
34 6 147
35 6 153
36 6 159
37 6 165
38 6 171

So you can get up to 37! with 165 pins, which is 1.38x10^43, which is much less than 2^168-1=3.74x10^50. Hmm. Eventually it's gotta get better with factoradic, which tends to infinity much faster than a fixed base raised to power, such as n^n > a^n over a certain threshold of n. But 165 pins is not past that critical point. Who can find the critical point where factoradic becomes a more efficient way to store numbers, than

Re:Oh no.

[sillybilly]

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 representation space, instead of a uniform 4 for all digits with Indian/Arabic numerals with space to blow to 9999, but 1900 only MCM, 3 digits, so near the focusing points, you get terser, at the cost of more verbose at the extreme of 3888. For one roman numerals require something like 2.9 bit representations for each digit out of 7 possibilities, while Arabic/Indian need 10 digits so like 3.1 bit digits for the same space. And overall, roman numerals are are much busier with more digits, even if less bit per digit, in the space to 3999, than Arabic ones. But right now, I feel too stupid, tired and lazy to keep on thinking like this. Maybe someone can carry on the philosophical discussion, and tell me why I feel like a dog chasing his tail? I keep thinking maybe one day I might catch it :)

Re:Oh no.

[sillybilly]

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:Oh no.

[sillybilly]

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...
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...

Compared the above to this unix-pussy:
    http://content8.pureandsexy.or...
It's light, simple, low on features, easy to debug.
And for closer inspection, under the hood:
  http://content8.pureandsexy.or...
It's still not that complicated, streamlined, and follows Einstein's principle of make it as simple as possible, but not simpler. It still has all the features of a pussy, properly implemented, headache free. You cannot get any simpler than that, or it's no longer a pussy.

When it comes to pussy, both are equally gorgeous, and functional. Variety is the spice of life. But when it comes to Unix, only the light, simple, easy to see, understand and debug, nonmysterious, low on complications but still getting everything done variety is what's beautiful.

Re:Malware

[i kan reed]

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:Malware

[jcochran]

Well, malware injection to the linux kernel isn't a mere possibility. The incident that happened back in late 2003 comes to mind.

Yubikeys?

[ArcadeMan]

You mean I can no longer use my Battle.net Authenticator for my commits?

Re:Yubikeys?

[Mr_Icon]

Battle.net authenticator uses TOTP, so yes, you can. :)

Finally as secure as MMO games

[Zan Lynx]

Finally the Linux kernel which runs almost the entire Internet is as secure as my MMORPG accounts. About time. :P

Re:Shitty analogy time

[i kan reed]

Yep, exactly. That's how I won a free meth lab.

Re:How does it work without a clock?

[ChadL]

I have a Yubikey that I use for encrypting my password stores (using the private id as one of several components passed to a pbkdf). It detects replays by verifying that every token has a larger counter then all prior used tokens (and the timer depending on the application).
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 has full specifications and documentation.

Re:Malware

[Zero__Kelvin]

"Well, malware injection to the linux kernel isn't a mere possibility. The incident that happened back in late 2003 comes to mind."

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 ...

"But this attack never had any chance of corrupting the mainline kernel. The CVS repository is generated from BitKeeper, it is not a path for patches to get into the BitKeeper repositories. So the code in question could only affect users who were working from the CVS repository. Kernels used by distributors probably do not come from that repository, and, as this incident has shown, illicit code can only remain there for so long before being detected."

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:How does it work without a clock?

[jcochran]

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.

Re:How does it work without a clock?

[Mr_Icon]

Yubikeys also support the HOTP standard, which produces 6-digit codes. This is what kernel.org actually uses, not yubikey's own implementation.

Re:Malware

[jcochran]

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.

Thumbs up

[Mister Liberty]

Let's see:
- Authenticated kernel source.
- Checksummed distro ISO.
- Eeprom subverted thumb drive.

keys are not issued to someone they are generated

[tota]

The user is not issued a key, he generates one and gives it to the repository administrator to get ssh access. This process is called *generating* a key, and you can publish the public key to anyone, including the repository administrator which will then use it to grant you access. The private key however.. should remain private.

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:keys are not issued to someone they are generat

[Mr_Icon]

There is no mistake here -- the ssh private keys are generated on the kernel.org provisioning system, encrypted to the developer's PGP key (which is verified using the PGP web of trust) and then emailed out. The developer then decrypts the ssh private key on their workstation using their own PGP private key. Our copy of the ssh private key is destroyed in the process, so we only keep the ssh public key. PGP web of trust is king in the kernel.org world.

Re:keys are not issued to someone they are generat

[tota]

Really, that's interesting and I stand corrected. Thanks.
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:keys are not issued to someone they are generat

[Mr_Icon]

Least amount of back-and-forth between the developer and the admin ("sorry, your key has to be at least 2048 bits", "you forgot to sign your mail", "sorry, I sent you guys the wrong key"), plus it helps assure it's a dedicated SSH key and isn't shared between many other projects and therefore copied across workstations. Mostly, though, it reduces hassle.