Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.
Klaus Reimer asked Is there already any feature to
run apt-get in a secure way? I mean that it installs only TRUSTED
packages.
.
Peter Cech suggested the features added by Connectiva in their port of apt
to RPM (see this editorial on
Freshmeat). Goswin Brederlow mentioned apt-get's cvs has a ssh method of retrieving files. Of cause you
would need ssh access to a save mirror.
John Goerzen replied helpfully:
I have been working with Ben Collins on this project already. You may find some documentation -- albeit somewhat out-of-date -- on this at the URLs below. The software is already written and will be showing up in Debian this weekend.
My draft spec:
gopher://gopher.quux.org:70/9/devel/debian/debsigs.ps (PostScript)
gopher://gopher.quux.org:70/0/devel/debian/debsigs.txt (Plain Text)This spec allows for multiple signatures per .deb with an eye towards flexibility and open policymaking.
Discussions involving cryptographic security seem to create substantial
confusion on Debian mailing lists, and this was no exception. A number of
posters thought that signed packages would be of little benefit unless a human
made the signatures. But, as Bernd Eckenfels said, It will [provide] additional security since corruption on the way
from master to the user (i.e. mirror or cd) will be detected.
Wichert Akkerman did, however, hint at a problem with giving dinstall a key, and Matt Zimmerman explained:
[Compromising dinstall] only affects packages currently on Debian mirrors, and once the compromise is fixed, things return to normal. If a trusted key were stolen, it could be used to sign packages and distribute them anywhere, and it is much harder to revoke a key from every Debian system than to repair a single system intrusion.
Also, once the key is revoked, older packages (e.g., from previous releases) signed by that key can no longer be verified.
Brian May proposed a work around - Would it help if
you could download the signatures separately from the package? That way [post
compromise] an existing CD could still be used, just down load the new
signatures (which would be much smaller then the packages themselves) from your
local debian mirror.
. Matt Zimmerman conceded Yes, I believe that would help.... Then we are back to the usual,
insoluble key management problem.
Jason Gunthorpe's comments provided a clearer idea of the current state of affairs:
Alfredo is porting his Connectiva code into APT4, the FTP masters and Release masters have agreed on a file format/etc and we will likely see signed *releases* for woody (I hope).
This means you can tell that you are using Debian 2.2rX from Debian itself with certainty no matter where you get it from, as long as you can get a trust path back to the signing keys (ie w/ HTTPs and Verisign).
Michael Bramer got busy coordinating the translation of messages you see when installing a package:
Debconf allow multi language templates files. But very few packages with templates files use this feature. (only debconf, base-config and roxen support several languages (=>5) )
I start to translate this week same templates and write bugreport. I set a web page to manage this translations.
see: http://auric.debian.org/~grisu/debian_translation/
If you like to help, to translate same (very little) texts, write this page. Translate one or two files in your language or check same translations and write bug reports.
Others joined the translation effort, but most of the thread was
spent discussing the 2-letter codes for languages and countries. Some
folks apparently confuse the two; for, according to Colin Watson,
I see roxen and roxen2 both use "se" for
Swedish translations in the above list, while the generally accepted
Swedish locale in most of the rest of Debian seems to be "sv"
.
Olaf Meeuwissen agreed with Colin,
Go ahead, file that bug report! The language tag `se' is used for Northern Sami. Swedish is sv.
See http://www.indigo.ie/egt/standards/iso639/iso639-1-en.html for details.
A few messages later, Olaf elaborated, quoting from some relevant standards documents:
On language codes the HTML 4.01 spec says:
6.8 Language codes
The value of attributes whose type is a language code ( %LanguageCode in the DTD) refers to a language code as specified by [RFC1766], section 2. [...]
Language codes are case-insensitive.
Then RFC1766 says:
The following registrations are predefined:
In the primary language tag:
- All 2-letter tags are interpreted according to ISO standard 639, "Code for the representation of names of languages" [ISO 639].And ISO 639 then says:
Technical contents of ISO 639:1988 (E/F) Code for the representation of names of languages
Two-letter lower-case symbols are used
Gustavo Noronha Silva also pointed out that languages may have
variatiants,
BTW, portuguese has two major "versions", pt_BR (brazillian), and pt
(or pt_PT, I don't know exactly) (portuguese), the page has only pt,
I'd like to know how is this diference handled, and how is it supported
in debconf... I translated base-config's debconf's template, I set it's
translated description field as pt_BR (see bug #83206).
Michael Bramer changed his script that generates the web page
to support xx_XX style language codes.
Martin Michlmayr, one of the hardest-working of Debian's Application Managers, made a proposal to slightly change the New Maintainer procedure. Though he made his proposal to the debian-newmaint-admin list, Glenn McGrath forwarded it to debian-devel, sparking a fairly large flame war. In his proposal, Martin said:
I have recently seen an increase in applicants who are unprepared or don't even respond to my initial or follow-up messages. I have the strong suspicion that this is related to the fact that it's really easy to sign up for NM -- simply enter your name and e-mail address, and there you go! You no longer have to think how serious you are about it and what you want to do for Debian.
My proposal is this: You can no longer apply to become a Debian developer yourself, but instead you need an existing Debian developer to recommend you. Nothing in the NM system changes except of the application itself. The developer who recommends another person as a NM is not responsible for him or has to go through the NM process with him (the latter will still be done by an AM) -- so this recommendation is no report to the DAM, but simply the entry ticket to the NM process.
How do you find someone to recommend you? Easy, if you meet a developer for key signing you can ask him to recommend you, or if you are active on the Debian mailing lists or help out with boot-floppies or a Debian port, I'm sure someone is willing to recommond you. Or, of course, a sponsor can do it.
This change would guarantee or at least increase the chance that applicants
- have a signed GPG key
- have a sponsor
- have had contact with Debian before
- have seriously thought about joining Debian
What do you think of this? I would like to implement this sooner than later, so please share your comments.
Finally, here are some statistics; these are the number of people who apply for NM each month. Of course I don't know how much increase is due to the dropping waiting time for NM and the easy-to-use web interface, but...
- 28 2000-03
- 22 2000-04
- 43 2000-05
- 36 2000-06
- 41 2000-07
- 47 2000-08
- 49 2000-09
- 63 2000-10
- 86 2000-11
- 64 2000-12
- 46 2001-01 (this month is not over yet)
Glenn prefixed the above with his own take on Martin's proposal:
There is a faction of debian developers who are elitists and want to close the system to new developers (numerous attempts have bee nmade by diffferent methods)
These sorts of arguments are devisive and counterproductive to debians goals, but i think this topic needs to satisfactorly be discussed and _concluded_. I think elitism is the only threat to debians viability. If the elitists gain power their will no doubt be a manpower shortage as there will be a lack of "worthy" new maintainers to do the work that the elitists want to hand to other people.
As expected, a few people on debian-devel had comments. There is a
faction of unabashed "elitists" who favour raising the bar of technical
competence. Ian Jackson, for one, is of the opinion that
anyone who thinks that it's a problem that
these procedures are elitist should not be a Debian developer, but
should go off and do something else. Elitism - ie a high standard of
techical excellence - is *exactly* what we're here for, and continue
failure to recognise that will lead and is leading to problems.
The consensus view, however, was that Glenn had misinterpreted Martin's proposal. As Julian Gilbey put it:
I think this is not, in any way, what Michael was suggesting. I don't know whether you have been following what has been happening in the New Maintainer arena for the last two years, but the rate at which people are currently being accepted into Debian is far higher than it has ever been before.
However, this is due to the stirling work of a large number of volunteers who are devoting part of their time to acting as Application Managers, gathering the required information from prospective developers and ensuring that they have the technical competence to do what they wish to do for Debian.
What many of the AMs are noticing, however, is that over the last couple of months, the people who are in the NM queue are more and more often either not interested in becoming developers, or they don't respond to emails, or they have no idea what they are doing, or they don't know what they want to do in Debian. I effectively ended up sponsoring one of my applicants until he was technically up to the level I felt was required of a developer (and if the developer concerned is reading this, I don't mean this personally).
What is the result of this? Applications are handled in general on a first-come, first-served basis, and the rate of applications being received is now significantly greater than that of them being processed. So the queue is going to grow again, despite our best efforts, but critically, those people who are actively already working for Debian and need to become registered developers to effectively do their work are being lost among those who have no idea. There is a system for putting applicants "on hold" if they are not ready, or don't respond, but it wastes the small amount of time that the AMs have to devote to this work, and thereby holds up those people who really ought to be in the queue.
The proposal is a simple one. Already, someone is only accepted as a new maintainer if they pass the requirements (all of which are documented explicitly on the website, see under http://www.debian.org/devel/join/newmaint). The suggestion is that they have to convince an existing maintainer to recommend them to the NM team before they will join the queue. Now, anyone who is seriously interested in becoming a new maintainer should already be actively involved in some aspect of Debian, either active on a list or working on a package through the sponsorship system. If they are so unknown that they cannot even find even one developer who is willing to put their name forward to the NM team, why are they applying in the first place?
If this proposal means that the number of applicants who just drop out of the process after wasting people's time is significantly reduced, then it is worth it. And if it means that applicants enter the NM system actually ready to become maintainers (with all the docs and experience etc required), then it will help many more people to join Debian far more quickly. And I do not envisage that a single applicant who would have got through will be prevented from doing so by this proposal.
So I see this proposal as a way of helping Debian to open its doors rather than the opposite.
Most of the posters to this thread saw it this way, and Glenn eventually
conceded,
it was wrong of me to brand Martin an elitist
.
Sam Hartman wondered,
What about trying something simpler like having a checklist of steps
that the maintainer should follow (already done) and requiring them to
check off that they have completed enough of them when they first
apply. I suspect that people would tend to tell the truth and to
self-select.
Unfortunately, says Martin Michlmayr,
There is a checklist and a big link from the application page; it
didn't work.
Craig Small got busy and implemented a checkbox system on the application form. This change passed from proposal to implemented in four days or less. That's gotta be some kind of record!
Julian Gilbey instructed:
To announce an ITP, please send a mail to submit@bugs.debian.org against the wnpp package with Severity: wishlist and subject line "ITP: packagename".
Don't send it to -devel directly; the BTS will forward it there *after* the ITP has been given a bug number.
Mark Brown could not confirm that the BTS was properly
forwarding the ITPs, and Sam Hartman suggested updating the Developer's
Reference to reflect the current procedure. Elsewhere, there was some
confusion over whether the new system even behaved as it had been described.
Mark Brown could not confirm that the BTS properly forwarded each ITP,
and Josip Rodin said, the BTS will not forward
it automatically to -devel, but to wnpp@d.o list. Unless someone has
implemented it while I wasn't looking... You need to put `X-Debbugs-Cc:
debian-devel@lists.debian.org' header (real header, not pseudo like Package)
in order for the BTS to CC: the mail (with the bug number in the subject
line) to -devel list.
Julian groaned and asked, could we modify the wnpp@debian.org alias in master:/etc/alias to
forward also to -devel? If this is agreed, I'll forward this message to
debian-admin.
Martin Michlmayr did not like that idea, since the
wnpp mailing list got a lot of traffic that didn't belong on -devel. At one
point, Josip added, There will be a new list created,
debian-wnpp@lists.d.o, and it will replace wnpp@d.o address. That way everyone
who wishes to see ITPs and all can subscribe to that list.
Julian
offered the suggestion that most people, although not avidly fascinated by
ITPs, still might be interested in the occassional one, but would rather
not subscribe to Yet Another List for something
of only marginal interest.
Brian May agreed, and added, If these messages aren't posted to debian-devel, you run
the increased risk of the problem not getting noticed until somebody asks
"how come you changed the name of your package?"
Close by in the
thread, Josip argued, the reason ITPs were posted
to -devel thus far is that there was no other more appropriate list, but the
information had to be posted somewhere where everybody could see it. With the
automated WNPP that can be browsed using the BTS and which has nicely sorted
web pages, and considering there's simply way too many ITPs etc these days,
another list looks like a logical step forward.
And Julian replied,
I guess you're right.
Matt Zimmerman wanted to take a leaf out of
OpenBSD's book and have a central CVS repository
for Debian code. As in OpenBSD, it would help
auditing efforts of the entire source tree, as
well as make it easier for the Security Team to
create branches from
older versions to backport fixes, and easily
extract individual changes (e.g. changes to a
particular source file between two upstream
releases) and merge them in
, increase peer
review, sharing and collaboration between
maintainers, and make it easier for maintainers
adopting orphaned packages to deduce packaging
decisions from its history.
Joey Hess provided a little background on a similar discussions in past two Atlanta Linux Showcases, especially on a cvs for Debian.
The idea we eventually decided would be a good one is to set up a system and import all of the sources in debian into it. After that, the system sits there and tracks packages as they are installed into the archive each day, and grabs the new version, checking it into cvs.
The resulting cvs archive would be generally read-only, at least in the beginning. Some developers may eventually opt to use it as the canoical archive for their package (typcially people who have been maintaining their own cvs repositories, and groups like the boot-floppies, I guess -- no need for two cvs repositiories in these cases).
But the good thing about doing it this way is it doesn't really change how things are done now. Developers can opt to not use cvs if they don't want to, and their uploads will still be automatically checked in.
There are some hurdles though:
system size
About 2 x the total unpacked source size of unstable, or 25 gb. Call it 30 gb to be safe, and this will need to be upgraded from time to time just as does the debian archive.
checking everything into cvs
This is a bit of a bear. Upstream tarballs that have CVS directories or symlinks in them are the main problems. Other problems include figuring out which files are binary and checking them in with -kb. These problems are all surmountable though.
tracking dinstall
Some degree of integration with dinstall is really called for.
Presuming we could find someone to donate the disk space, I think it would be worth it. Matt listed some of the nice benefits it would yeild.
Predictably, one of the first questions raised was about the infrastructural requirements for this enterprise. Matt clarified that he had in mind only the code for standard and higher-priority packages. Joey Hess provided some real data on the size requirements of selected packages:
Package Current tree size Repository size Revs Growth debconf 726 kb 4.2 mb 294 5.8 boot floppies 9.7 mb 48 mb 74 4.9 bsdgames 7.3 mb 9.2 mb 28 1.26 sphinx2 24.5 mb 25 mb 3 1.02 xjewel 261 kb 291 kb 7 1.11 aalib 1.2 mb 1.5 mb 23 1.25 Revs is the number of revisions since it entered cvs (roughly: it doesn't count cvs commits w/o a debian revision, or branches so is low for boot floppies).
Growth is repository size divided by current tree size.
Most of these packages have been in cvs for years and years. I picked them randomly from what was at hand. While it does demonstrate that packages that undergo a _lot_ of revisions (debconf) or that are developed for a long time in cvs (boot floppies), can see large growths in the repository, it also indicates that more typical packages that are not debian-native, and receive only modest numbers of revs tend to see growths of only 1/4 again their size in the repository over a period of 3 to 4 years. In fact, my entire repository (56 packages) is just 1.8 times the size of the current source trees.
The ed-diff-like format used by rcs is quite efficient.
Matt provided some data on his efforts:
Today, I imported the rest of standard into my CVS repository. Here are some statistics:
142 source packages 173Mb 121 source packages made it into CVS 138Mb Repository size 598Mb Average source package size 0.82Mb Average repository size per package 4.94Mb Checked-out CVS tree 593Mb
Junichi Uekawa commented in the subthread on
the overloading of CVS servers that There are many projects which
seem to be working with a distributed CVS
system. cvsup seems to be used quite widely, and
making mirrors of CVS sites seems to be done quite
efficiently. [...] And I have checked out the
repository for OpenBSD to see how they have done
it. They have cvs (anonymous read-only) mirrors
all over the world, just like we have loads of ftp
mirrors around the world. It has been done
before, and does not sound like a completely
unreasonable argument.
Matt's last update to the list was:
I've been updating the repository about once per day. I just recently finished automating the process, and the repository now contains 156 (package,version) pairs for 142 packages.
I have put the repository up for viewing with viewcvs here
http://alcor.ddts.net/cgi-bin/viewcvs.cgi/debian/?cvsroot=Debian-test
Not surprisingly, the most oft-changed package is debconf, with 5 uploads in the past 8 days. Other packages with several revisions include rblcheck, cpio, and console-data (all with 3 revisions). Look to those packages if you want to see anything interesting.
Other discussion (predictably, for Debian!) ranged over the use of the repository to satisfy clauses of the GPL license on source code availability.