| Author |
Message |
Lars Wirzenius
*nix forums Guru Wannabe
Joined: 01 Mar 2005
Posts: 168
|
 Posted: Tue Nov 29, 2005 12:50 am Post subject:
Re: Checksumming tool
|
|
|
ma, 2005-11-28 kello 18:20 -0600, Adam Heath kirjoitti:
| Quote: | On Mon, 28 Nov 2005, Lars Wirzenius wrote:
File: foo%20bar/hellurei.txt
Size: 12345
MD5: 012345667
SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Mode: 0644
Checksum:
md5: 0123456789[B
sha-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Having the names of the checksums be the header names could lead to clashes.
|
That's a point. I think I'd leave out the colon after the checksum name,
or possibly change it to an equals sign:
Checksum: md5=123123123123123
sha-256=aaffaaffaaffaaffaaff
Those are pretty small details, though, I could easily live with any of
these.
--
sic transit discus mundi
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Anthony DeRobertis
*nix forums Guru Wannabe
Joined: 15 Mar 2005
Posts: 104
|
| Posted: Tue Nov 29, 2005 2:10 am Post subject:
Re: Checksumming tool
|
|
|
Lars Wirzenius wrote:
| Quote: |
The best I've come up with so far is a pseudo rfc822 syntax:
File: foo%20bar/hellurei.txt
Size: 12345
MD5: 012345667
SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Mode: 0644
|
anthony@feynman:tmp$ md5sum test
04c09e317db0addf12be8d1a4e2b9e37 test
anthony@feynman:tmp$ sha1sum test
35a980f320a5f72b11f3616c476fab2844118879 test
That format is extremely easy to work with using basic Unix commands
like grep, cut, sort, diff, etc. The one you've come up with is not.
Please, keep the useful one record (file) per line format. Is there
something wrong with:
LINE = TAG DELIM1 HASH DELIM2 FILENAME
DELIM1 = " " | "-" | ":" | ... (pick one)
DELIM2 = " "
If you let DELIM1 be either "-" or ":" and DELIM2 be " " then you are
backwards compatible with both md5sum and sha1sum by making 32-character
untagged hashes mean MD5 and 40-character ones mean SHA-1.
sha-256:<<blah,blah,blah>> test
is so much easier to deal with than rfc822 stuff.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Tue Nov 29, 2005 5:20 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote:
| Quote: | I would expect something like
$ dsum -a sha1 COPYING; sha1sum COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING
|
sha1sum already exists; and isn't that long. Do you mean sha256?
Cheers,
aj |
|
| Back to top |
|
|
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Tue Nov 29, 2005 5:20 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Mon, Nov 28, 2005 at 12:09:33PM -0600, Peter Samuelson wrote:
| Quote: | I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
sense, like s- for sha-256. Avoids the filename encoding issue you
mentioned later (unless we want to encode newlines).
|
The encoding issues are only for doing base64 (or similar compression)
or filename encoding, so you can't avoid them :)
| Quote: | OTOH, it would be far more convenient for *us* if it supported the
.changes style we use, ie:
MD5Sum:
hash size filename
This might be generally reasonable,
|
Doesn't matter if it's generally reasonable, it's needed by *us*. That's
the format we use in .changes, in .dscs and Sources, and in Release.
It's silly to have a useful format, then not have tools that
conveniently check it, particularly if we're writing our own.
| Quote: | $ dsum -a sha1 foo; sha1sum foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
f572d396fae9206628714fb2ce00f72e94f2258f foo
$ dsum -d foo
SHA1Sum:
f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
$ dsum -b foo
SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f
What's the " 6 " above?
|
wc -c foo. foo was "hello\n" for reference. (And it probably should've
been SHA1: not SHA1Sum: too)
| Quote: | (Note that "dsum" would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)
Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on
i386, plus a trivial amount for dsum itself. I wonder if it'd be
better to just copy / paste the algorithm code into dsum.
|
libssl0.9.8 is 860kB of .deb, 2MB installed. It's possible that libssl
would be too much of a nuisance wrt transitions to use, at least
dynamically.
Cheers,
aj |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Tue Nov 29, 2005 12:10 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Thomas Bushnell BSG <tb@becket.net> writes:
| Quote: | Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
The archive signing key gives absolutely no integrity ensurance on the
deb package. The only thing it insures is that the file was not
altered _after_ leaving ftp.de.debian.org for the mirrors and/or
user. In no way does it prevent altering the deb on ftp-master.
Isn't that a useful assurance? Perhaps I trust the maintenance of
ftp-master, but not the maintenance of Joe Random Mirror.
|
It sure is usefull as it removes a lot of untrusted steps from being a
vulnerability. But that doesn't help if the attack happens at
ftp-master.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Tue Nov 29, 2005 1:10 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
"Steinar H. Gunderson" <sgunderson@bigfoot.com> writes:
| Quote: | On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote:
Moving away from MD5 is certainly not a bad idea, but it's not clear
whether the alternatives are any better. Sure, everyone recommends
SHA-256 at this stage, but nobody can give a rationale.
MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or
higher) are significantly harder to break in practice, and there's
nothing better yet.
Just a comment here for those who are not used to hash functions: "Broken"
here means that you can generate collisions faster than using the birthday
attack (2^64 for MD5, 2^80 for SHA-1). It does not have to mean that you
can do _really_ evil stuff, like generate a second file with the same MD5
hash as a given file (so-called "second preimage", IIRC) and to the best of
my knowledge, nobody has done so yet).
|
According to slashdot articles you can generate human readable files
(like the Packages file) with md5sum collision in ~45minutes on a
modern cpu now.
I think that counts as broken. Luckily for us we also have the size of
the file.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Tue Nov 29, 2005 1:20 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Anthony Towns <aj@azure.humbug.org.au> writes:
| Quote: | On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote:
Anthony Towns <aj@azure.humbug.org.au> writes:
.deb signatures are aimed at giving users some sort of assurance the
package is "valid"; but when you actually look into it -- at least in
Debian's circumstances -- those signatures can't actually give any
meaningful assurance for any specific validity.
Don't they give the user the assurance that a Debian developer was
responsible for building and providing the package?
Not really, they give the assurance that it was built by someone who at
some point possessed a key that at some point was considered sufficient
to identify a Debian developer or a buildd.
What assurance would you take from a package signed by Chip's old key?
(And why do you think it's actually helpful? Debian developers build
*lots* of crap, especially if you can't differentiate stuff uploaded to
Debian and not)
Cheers,
aj
|
They also upload *lots* of crap. Should we stop using Release.gpg now?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Florian Weimer
*nix forums Guru
Joined: 19 Feb 2005
Posts: 418
|
| Posted: Tue Nov 29, 2005 1:30 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
* Anthony Towns:
| Quote: | On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
For the "exploits" we have seen so far to work, the malicious party
needs upload access to the archive and has to plant a specially
crafted package there, for which they have created an evil twin
package. (Same for attacking one of the text files listing hashes.)
Looks a bit far-fatched to me.
Not really. Joining Debian isn't particularly difficult, and it might
not even be out of the question to find someone who'll sponsor an upload
without rebuilding the .deb. I think it's safe to imagine that there are
developers right now who've done some shady things in the past; is it
that far fetched to imagine it's worth protecting against developers
who try to abuse their priveleges?
|
No, but they can directly upload a bad package. No need to create an
MD5 collision and sneak the "evil twin" package into some mirror
archive.
| Quote: | The way we do that has to be mostly after the fact, of course: someone
uploads a bad package, people find out it's bad, we trace it back to
whoever uploaded it, then we kick them out of the project.
|
Have we already done that? Have we expelled people becaue they put
vulnerable code into Debian?
| Quote: | But that only works if the bad package is actually discovered. If the
.deb's distributed across hundreds of mirrors and to thousands of users,
it's reasonably likely that it will be discovered; but if it's possible
to target the attack against an individual user, and leave the rest of
the Debian universe untouched, you've got a much better chance of
not getting caught. Hence: distribute an iced .deb in the archive, that
does no harm ever and thus needn't arouse any suspicion; and sneak a
fire .deb that has the exploit activated onto the mirror of your target.
|
You can embed code that checks for characteristics of the victim
system and activate the attack only if there's a match. The advantage
is that you need only to compromise a DD account (or become a DD
yourself), and not both a DD account and part of the mirror cascade
which is used by the victim.
| Quote: | "Looks a bit far-fetched" comes under the "famous last words" heading
for security analysis.
|
One part of security analysis is figuring out which potential attacks
are relevant. Keep in mind that most attacks never happen. There's
no point in wasting resources on irrelevant attacks. It's
embarrassing to be wrong on such matters, in both directions. Money
thrown at a problem that turns out to be a non-issue is money lost.
But you hardly ever read about those failures.
There is one attack on MD5 which is a significant threat to many
companies: the PR attack. There are many, many security experts who
are all too willing to label your system as broken just because it
uses MD5 internally. With the right media spin, such claims of
insecurity can become a PR nightmare and very costly.
| Quote: | Worse, the existance of a practical md5(A+B+C)=md5(A+D+C) attack means
that it's not out of the question that there're md5(A+B)=md5(C+D)
attacks in the hands of particularly well resourced groups (which is
worse, since the version uploaded to the archive could then be entirely
innocent looking). Personally, I don't have any interest in making the
NSA's job any easier, or that of other signals intelligence groups.
|
Oh, many Debian packages happily leak so much data over the network
that I often wonder if it is feasible to create user profiles using
this information. 8-)
| Quote: | SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better
than 512 bit RSA keys.
|
No, the algorithms are somewhat different. It's easy to build a 256
bit hash which is less secure than a 160 bit hash, so it's not really
comparable to the RSA situation.
| Quote: | MD5 is broken, and isn't extensible. SHA1 is fragile, but not
broken, and is extensible.
|
What do you mean with "extensible"? Both MD5 and SHA1 are based on
MD4, and SHA256 is based on SHA1, but AFAIK, no rationale for the
changes from MD4 -> SHA1 and SHA1 -> SHA256 has been published. (Ron
Rivest explained his changes from MD4 to MD5.)
| Quote: | In terms of security, there are some better hash functions.
My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha.
|
Neither MD5 nor SHA1 have received much public scrutiny. Dobertin's
work on MD5 has never been fully published. I've already joked that
the difference between Wang et al. and European or U.S. cryptographers
is that the Chinese government doesn't tell their researchers not to
publish their results. 8-P
| Quote: | IIRC, the elliptic curve cryptography stuff was supposed to be
similarly neat, until people started analysing it seriously, at
which point it broke.
|
The NSA has recently licensed ECC patents from Certicom.
There are weak elliptic curves as far as cryptography is concerned,
but there are also others: inefficient ones and those which have been
patented by Certicom.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Tue Nov 29, 2005 1:30 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Steve Langasek <vorlon@debian.org> writes:
| Quote: | On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote:
Steve Langasek <vorlon@debian.org> writes:
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote:
That's easy: you trust the Packages file to be correct when using apt,
and it's not verified at all by per-package signatures.
In what way trust and how does that change anything?
At best you can prevent a newer version of a package to appear in the
Packages file by compromising it. You can't subvert a package itself.
But you can already ship yesterdays Release.gpg, Release and Packages
file to a user and thereby prevent any updates.
On the other hand, without package signatures ftp-master adds a
vulnerability. You can hack into it, replace debs, recreate the
Packages, Release and Release.gpg file and thereby infect users. With
signed debs that could still be detected by every user in apt-get.
Only if every user is in a position to verify signatures from each Debian
developer individually, which is completely unrealistic.
Up to a point you can trust the keyring. As much as you can trust any
DD signature. You try to argue that signatures are not absolutely
trustworthy but that is nothing new.
I'm arguing that a 5-hop-long signature chain to establish the validity of a
Debian package is as good as useless, and worse if the user doesn't
understand this.
And a 5-hop-long signature chain does *not* mean that anyone in that chain
trusts the person holding the key on the end to upload packages to Debian.
|
They aren't ment to. The in-deb signature by the DD is only ment to
say "I did build this".
| Quote: | The only thing we have that establishes *that* is the presence of the user's
key in the Debian keyring, so then you have the logistical problem of how
arbitrary users are supposed to verify whether a given key is in the
|
They aren't supposed to. They just should have the possibility.
| Quote: | keyring. The debian-keyring package doesn't get updated every time there's
a key added or removed, and the web interface to keyring.debian.org doesn't
provide any cryptographic assurances. Oh, and BTW, check the IPs of
ftp-master.debian.org and keyring.debian.org...
|
The amount of package that fall through the cracks due to the keyring
not being fully updates is marginal. You can also ask keyservers for
keys and verify them through your trust path. That is enough to
establish who build the deb (not to be confused with for whom did he
build it).
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Tue Nov 29, 2005 1:30 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
"Steinar H. Gunderson" <sgunderson@bigfoot.com> writes:
| Quote: | On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote:
Well, even if I know naught about it, it looks to me that having
something signed is better than having the same something not signed.
Sorry, but that's a snake oil rationale.
A: Why do you lock your car up[1]?
Because it makes it harder to steal the car.
I think the point was that signing a .deb did not automatically make it
harder to do whatever the scenario asked for.
/* Steinar */
|
Why do you put a serial number on the car?
So you can trace it back to the true owner when you find a car that
was repainted.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Tue Nov 29, 2005 1:40 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Anthony Towns <aj@azure.humbug.org.au> writes:
| Quote: | On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote:
You're correct.
And he is also wrong.
That would result in debs with the same name and version but different
md5sums. Something that easily confuses apt-get and people.
And yet, somehow people manage partial cross-grades between Debian and
Ubuntu...
Regards,
aj
|
I said confuse. Doesn't mean it won't work at all. But apart from
stuff not getting cross-graded (as you put it) you can also end up in
loops that will re-cross-grade a package every time you apt-get
upgrade and the like.
Having apt-get say there is a new version of foo available every day
is damn anoying.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Jochen Voss
*nix forums beginner
Joined: 03 Jul 2005
Posts: 25
|
| Posted: Tue Nov 29, 2005 2:00 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Hi!
On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote:
| Quote: | According to slashdot articles you can generate human readable files
(like the Packages file) with md5sum collision in ~45minutes on a
modern cpu now.
I found the example at http://www.cits.rub.de/MD5Collisions/ quite |
impressive. They have two different valid PostScript files with
identical MD5 sums. I don't know how much computing time they used,
though.
All the best,
Jochen
--
http://seehuhn.de/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Florian Weimer
*nix forums Guru
Joined: 19 Feb 2005
Posts: 418
|
| Posted: Tue Nov 29, 2005 2:31 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
* Jochen Voss:
| Quote: | On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote:
According to slashdot articles you can generate human readable files
(like the Packages file) with md5sum collision in ~45minutes on a
modern cpu now.
I found the example at http://www.cits.rub.de/MD5Collisions/ quite
impressive. They have two different valid PostScript files with
identical MD5 sums. I don't know how much computing time they used,
though.
|
None, many of these examples were created before the collision
generation tools were generally available. The "exploit" uses some
properties of Postscript files which make them not very desirable for
storing electronic documents which cannot be altered. For example, it
is possible to create a Postscript file whose output, when printed,
varies from printer to printer.
(Note the "rub.de" part of the URL. A clear warning sign.)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Henning Makholm
*nix forums Guru
Joined: 21 Feb 2005
Posts: 310
|
| Posted: Tue Nov 29, 2005 2:50 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Scripsit Anthony Towns <aj@azure.humbug.org.au>
| Quote: | On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote:
I would expect something like
$ dsum -a sha1 COPYING; sha1sum COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING
sha1sum already exists; and isn't that long. Do you mean sha256?
|
Feh. Yes, I meant SHA-256. Sorry for the confusion.
--
Henning Makholm "What has it got in its pocketses?"
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Henning Makholm
*nix forums Guru
Joined: 21 Feb 2005
Posts: 310
|
| Posted: Tue Nov 29, 2005 4:20 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Scripsit Florian Weimer <fw@deneb.enyo.de>
| Quote: | * Jochen Voss:
I found the example at http://www.cits.rub.de/MD5Collisions/ quite
impressive. They have two different valid PostScript files with
identical MD5 sums. I don't know how much computing time they used,
though.
|
They claim a few hours:
| Based on [WY05] and the analysis described in [Da], we implemented
| an attack to find random collisions for the MD5 compression
| function. It took just a few hours on a customary PC.
| Quote: | None, many of these examples were created before the collision
generation tools were generally available.
|
They did create or use a collision, as anyone can verify simply by
downloading the files. Whether or not they used a generally available
tool is not important to the fact that a collision was actually
generated.
| Quote: | The "exploit" uses some properties of Postscript files which make
them not very desirable for storing electronic documents which
cannot be altered.
|
There is absolutely no reason to put the word exploit in scare quotes
here.
You might want to notice that the "properties" you apparently think
invalidate the example are also shared by many common formats for
software. An ELF binary can easily be crafted to contain a blob of
initialized data whose contents are only used for checking whether to
enable some malicious machine code that is always present - and this
would not be easily detectable at all.
The only thing that would seem to make it less than straightforward to
craft a similar attack consisting of two different .deb files with the
same MD5 sum of which one behaves maliciously, is the need to trick
the CRC-32 in the gzip trailer for data.tar.gz simultaneously with
tricking MD5.
But a CRC-32 is, to put it mildly, not much of a defense against a
determined attacker! All it takes to beat *that* is finding at most 33
different MD5 single-block collisions in sequence; it is then a matter
of extremely simple linear algebra find a nontrivial combination of
them that cancel out each other's effect on the CRC.
Note that the gzip compression format allows blocks of compressed data
to specify use of the "no compression" algorithm, so injecting your
collisions in a gzipped data stream is trivial, too.
| Quote: | (Note the "rub.de" part of the URL. A clear warning sign.)
|
The nice thing about ad hominem arguments is that you can make them
without ever having to argue the merits of your case.
--
Henning Makholm "I always thought being *real* sad
would be *cooler* than acting *fake*
sad, but it's not. It's not cool at *all*."
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
Distributions
»
Debian
»
devel
