Re: Volantino evento traduzioni
On Tue, Dec 02, 2003 at 10:24:47AM +0100, Stefano Canepa happily wrote: Io vorrei partecipare all'evento e visto che traduco anche per gnome rilancer? l'invito nella lista dei traduttori di gnome. Non sono sicuro Fantastico! A Genova ? stato distribuito visto che c'era un banchetto Debian. Grazie, Ciao, Carlo -- GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975 - The algorithm to do that is extremely nasty. You might want to mug someone with it. -- M. Devine, Computer Science 340
problem de creation de paquet
hola j'essaye de construire un paquet debian d'une application dans le repertoire doc, j'ai 2 scripts shell, lorsque je cree l'archi du paquet, je l'ai retrouve en non executable ! je vois pas pourquoi les permissions changent une idee ? merci -- (concatenate 'string lam (reverse gro.ylimafxut@))
Re: Bug#222730: ITP: zope-groupuserfolder -- group management for Zope
On Tue, 2 Dec 2003 [EMAIL PROTECTED] wrote: This package is an empty dummy package that always depends on a package built for Debian's default Python version. Why that. It should depend from Debian's Zope version or if explicite Python dependency is needed for one or the other reason it should depend from the Python version Zope is dependant from. This is not automatically the default Python version. Kind regards Andreas.
Re: popularity-contest
[Gürkan Sengün] I could not reach [EMAIL PROTECTED] which is mentioned on the following page: http://people.debian.org/~apenwarr/popcon/ Are you aware that the popcon project are now on alioth? URL:https://alioth.debian.org/projects/popcon/ The work stopped up a bit because of the break-in, but we are a small group maintaining it now.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 02:57:11AM +0100, Bernd Eckenfels wrote: On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. Yes but also the debian servers would not have been vulnerable if they had used 2.4.23. At least not at that point in time. They also would not have been affected if they were running 2.2.x. Why don't we just downgrade them all, then? -- gram signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Tue, 02 Dec 2003, Tom wrote: Yes but the attacker did not steal the DD's computer. He rooted it remotely. So the machine is rooted remotely, the DD logs into a debian box even using our new fangled smart cards, and the attacker still can control the connection. In this particular intrusion vector, the use of a smart card merely means that the attacker has to trojan the ssh binary on the compromised machine and use it to run a command that opens a shell under the DD's uid on a non-privledged port, thus circumventing the smart card in its entirety. If you log into a machine from a compromised machine using any means I can forsee today, the attacker can always control the account of the machine logged into, because the attacker effectively become the user of the machine. Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote: On Tue, 02 Dec 2003, Tom wrote: Yes but the attacker did not steal the DD's computer. He rooted it remotely. So the machine is rooted remotely, the DD logs into a debian box even using our new fangled smart cards, and the attacker still can control the connection. Not while the smart card isn't inserted. In this particular intrusion vector, the use of a smart card merely means that the attacker has to trojan the ssh binary on the compromised machine and use it to run a command that opens a shell under the DD's uid on a non-privledged port, thus circumventing the smart card in its entirety. I don't understand this objection, but it seems valid. Could you explain? If you log into a machine from a compromised machine using any means I can forsee today, the attacker can always control the account of the machine logged into, because the attacker effectively become the user of the machine. Yes, I always warned my employer that all I have to do is own your machine before you plug in your smart card, leave a logic bomb to do something while you're connected, wait for you to hang up and then report back. But it's all layers, layers, layers. More layers = better, none is a panacea. Have you ever used smartcards? I think that the more layers the better.
Re: [debian-devel] Re: more details on the recent compromise of debian.org machines
A levelezm azt hiszi, hogy Matt Zimmerman a kvetkezeket rta: On Fri, Nov 28, 2003 at 10:08:45AM +0100, Bernd Eckenfels wrote: In the final announcement I would add also a statement about reducing the number of trust relations between the machines and perhaps limiting shell access. It seems fairly clear that this was not an issue because the compromised user had accounts on all of the relevant systems. It occurs to me that -limiting shell access did save one machine for some time -this machine had been compromised using a trust relationship between it and an other compromized debian machine The question (as ever): What is the good balance between security (limiting access and trust relationship in this case), and efficiency of processes (debian developers' work in this case)? I demand that the above may or may not mean that trust relationships and shell access should be restricted, but certainly means that the possibility and impacts of such measures should be thought about. -- GNU GPL: csak tiszta forrsbl
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
[NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into private mail, but your e-mail address was munged in some sort of anti-spam measure, and not trivially un-mungeable. Please consider providing information on how to demunge it in some X- header, or not using munging at all.] On Wed, 03 Dec 2003, Tom wrote: On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote: the attacker still can control the connection. Not while the smart card isn't inserted. Well, the DD can't log in without the smart card, so that's clearly a prerequisite. the use of a smart card merely means that the attacker has to trojan the ssh binary on the compromised machine and use it to run a command that opens a shell under the DD's uid on a non-privledged port, thus circumventing the smart card in its entirety. I don't understand this objection, but it seems valid. Could you explain? If you have adjusted ssh, you don't need to show the compromised user the output of all the commands that are being run on the other end of the connection. Have you ever used smartcards? Unfortunatly, yes. I think that the more layers the better. Sure, I'm just saying that the cost to put 1000 smart cards with the requisite hardware in all of the places that DD's log in from doesn't give us enough extra security to merit the extra cost. Of course, if someone was to design such a system, work all of the bugs out, and get a hardware vendor to deploy it to DD's, I wouldn't stand in the way. [I would personally rather see paired random number generators than smart cards, but we're a bit too spread out for that to be much of a reality.] Don Armstrong -- You could say she lived on the edge... Well, maybe not exactly on the edge, just close enough to watch other people fall off. -- hugh macleod http://www.gapingvoid.com/batch8.htm http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: UserLinux white paper
On Wed, Dec 03, 2003 at 08:24:09AM +0100, Bernd Eckenfels wrote: | This is the Proprietary software model, with artificial, government | imposed (via copyright laws) monopolies, resulting in customer lock-in | and price maximization. | | I dont see a monopol, at least no government imposed. I believe that when Zenaan was saying was the copyright laws /are/ a government-supported monopoly on distributing a particular creative work (in this case, a piece of proprietary software). Cameron.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote: [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into private mail, but your e-mail address was munged in some sort of anti-spam measure, and not trivially un-mungeable. Please consider providing information on how to demunge it in some X- header, or not using munging at all.] Heh. That's my actual email address. Fooled ya. Well, the DD can't log in without the smart card, so that's clearly a prerequisite. You leave it unplugged until you need it, do your thing, then unplug it. Sure, I could still infect your toolchain so you unwittingly upload trojaned stuff. But the fact is in this *actual* compromise the password was stolen and the hacker worked later at his leisure: smartcards would have prevented this *actual* incident (but of course doesn't prohibit other ways of attack). If something could have prevented something that actually happened, I say go for it.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: If something could have prevented something that actually happened, I say go for it. Oh, one last thing: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? This is a big deal.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote: I agree that smartcards would help a lot. However as has been previously suggested the cost of 1200+ smart-card readers is probably prohibitive. What about RSA tokens? This solution does not require any special hardware to connect on the client side. Cheers Artur
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, 03 Dec 2003, Tom wrote: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? Could it possibly be because equipment is expensive and plane flights around the planet are not cheap? I know few DDs who are independently wealthy, and frankly, requiring volunteers to spend large amounts of money so they can volunteer their time isn't something that we should be doing, nor do I really see the project as a whole supporting such an action. Please feel free to produce code and take action to prove me wrong though. Don Armstrong -- UF: What's your favourite coffee blend? PD: Dark Crude with heavy water. You are understandink? If geiger counter does not click, the coffee, she is just not thick. http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: [custom] Debian Enterprise - packages
On Tue, 2 Dec 2003, John Goerzen wrote: First of all. This is obviously not a Debian projects I see it clearly as Debian project and can't find the rationale why you sais that it is _obviousely_ not. (since it is not operating within the Debian framework.) Why. If I see this right Zenaan is planning the depandencies for the meta packages he wants to build. As long as there is no debian-enterprise list created he has no other chance than using debian-devel to discuss this topics. It was the same for Debian-Jr, Debian-Med, etc and nobody thought that this whould not fit into Debian framework. I don't see why this then necessitates over a dozen threads on debian-devel -- AND why it gets to call itself Debian. Moreover, I remain unconvinced that there is any need to split from the regular Debian framework, especially since it seems that all you're doing is removing choices. ... or rather giving suggestions, what might fit well into Enterprise framework as we did fro children in Debian-Jr. (Though I admit I killfiled the earlier threads on the topic because they were too unwieldy) Anyway: Perhaps this is the reason. On Wed, Dec 03, 2003 at 02:45:51PM +1100, Zenaan Harkness wrote: * Office Suite - OpenOffice (there's no other near as feature complete) And OpenOffice is the only one that runs on only two -- yes, two -- architectures that Debian supports. Which is a problem for Debian and not for Debian-Enterprise or any other Custom Debian Distribution. * Scripting Language - Python (no one will debate this one :) If you think you can get every large enterprise worldwide to standardize on a single scripting language -- much less get even ONE to do that -- then you will surely be nominated for several nobel prizes. :) This is the only part of your mail I do completely agree with. Kind regards Andreas.
Re: [custom] The term flavor and encouraging work on Debian
On Wed, 3 Dec 2003, Fabian Fagerholm wrote: In my view (as I said), it would be logical to name a further subdivision of that product flavor. I like this interpretation of the term flavor and it would be easily applicable for Debian-Med to flavors like: - Medical practice - Medical research - Microbiology - Dental practice - Veterinary medicine - ... Ok. Semantics, of course, but that's what's being discussed here. :) I just think Custom Debian Distribution is not a very innovative phrase, it is too general to instantly give someone an idea of what it's about, and on top of all, it's quite long. ACK. That's why other people invented terms like Fedora. It just says nothing and so int can't cause false implications. It has to be defined precisely before it is a term to work with. Kind regards Andreas.
Re: [custom] The term flavor and encouraging work on Debian
On Tue, 2 Dec 2003, Fabian Fagerholm wrote: Actually, I'd like to see the term Custom Debian Distribution be set aside because a custom something is created each time someone modifies an original. Debian Enterprise certainly is an original. By the time a capable sysadmin has installed it, it will (probably) be custom. (Custom Custom Debian Distribution, anyone ?) The term suggests that the distribution is not-Debian, which is unneccessary and confusing. As non native speaker and also in general I try to avoid joining stupid naming discussions. But here is the weak part of the name we have choosen which has definitely to be clarified in an announcement of those people who invented the term. Kind regards Andreas.
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote: On Tue, Dec 02, 2003 at 06:05:44PM +0100, Andreas Metzler wrote: Joey Hess [EMAIL PROTECTED] wrote: Goswin von Brederlow wrote: dpkg that it is downgrading the package, and a clever attacker might avoid even that. How would you avoid it? Make the replacement package really be a different package entirely, of a higher version than the package it purports to replace. I think aj had some more examples along these lines the last time this came up. I still don't understand how you change the version number (or the package-name) without breaking the signature. You change the contents of the compromised Packages file, so that Package: bash Essential: yes Priority: required Section: base Architecture: i386 Version: 2.05b-12 is accompanied by Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb that information is already embedded in the .deb. Try dpkg --control foo.deb; cd DEBIAN; ls. apt should sanity-check whether that information matches the information it already has (from, e.g., the Packages file). If not, it should scream as loud as possible. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote: Hi, Henrique de Moraes Holschuh wrote: On Tue, 02 Dec 2003, Wouter Verhelst wrote: So unless you have a suggestion that would solve this particular issue, I'm afraid this idea won't work in practice. We could verify if the gpg agent (gpa? I forget the name...) cannot do this over a secure channel. It should be able to, and if not, it can probably be taught to. It's not that easy (basically you need to tunnel the actual encryprion/signing function, not just the passphrase-getting). See ssh-agent as an example. The good thing is that people are already thinking about this. http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html Well, implemented as Werner suggests in that message would require me to send the actual .deb over the line. I won't do that, since I don't have the bandwidth (or, in many cases, the time to wait for the download to finish; arrakis runs behind an ADSL line, while quickstep behind my cable modem. upstream speeds aren't that fast (and I regularly handle their mails at work)). As I understand it, an OpenPGP signature is an encrypted hash or something similar of the actual data. It would be feasible if the signature algorithm would allow for hashing the data on the remote machine, and signing that hash locally. Then again, we could do such things right now. Wouldn't it be more interesting to gpg-sign md5sums of control.tar.gz and data.tar.gz? Especially in the case of larger .debs, that would probably reduce the actual signature size as well... -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 20:34, Artur R. Czechowski [EMAIL PROTECTED] wrote: On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote: I agree that smartcards would help a lot. However as has been previously suggested the cost of 1200+ smart-card readers is probably prohibitive. What about RSA tokens? This solution does not require any special hardware to connect on the client side. What is a RSA token? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Revival of the signed debs discussion
On Wed, Dec 03, 2003 at 06:50:09AM +0100, Goswin von Brederlow wrote: Bernd Eckenfels [EMAIL PROTECTED] writes: How often has this person glance over the results? As I understand debian build daemons run unattended and build continously. Correct me when I am wrong here. But if I asume righ, I dont want to lose that processing speed, especially since it can be easyly compensated with 3rd party timestamps. In theory every build log is read. In praxis I believe all buildd admins scroll through the log and look for some obvious signs of errors before signing. I don't expect them to read a 17 MB logfile line by line for example. Well, actually... All failed logs are examined to find the cause of the failure and to decide on further action. All successful logs get their .changes extracted, signed, and mailed back. This is often done semi-automatically; in my case, this script is used: #!/bin/bash cat $1 ~/buildd/orig cat $1 | sed -e '9,/\.changes\:$/d' -e '/^\*/,$d' ~/buildd/changes cat ~/buildd/changes $1 together with some mutt hooks that allow me to just hit ryd for as many successful logs in my mailbox (and my gpg passphrase on the first one). IOW, I don't really look at successful messages anymore; if a build succeeds, it is assumed to be OK (which is why running regression tests at deb build time is a good idea, and should be done if at all possible). They do run mostly unattended, and do build continuously; it's just so that as-of-yet unsigned packages are put in ~buildd/build instead of ~buildd/upload (they're moved once the signed .changes arrives by mail) But even without reading having an actual person handling the signing has advantages. In case a buildd is compromised the signing still isn't. The attacker can't start and upload 500 backdoor packages pretending to be something else without raising red flags. Also failures in the buildd behaviour have to be cought, like building empty debs all of a sudden. A quick glance at the package contents listed in the build log will detect that. Even considering the above, this is still true. We keep an eye on our systems; maintaining an autobuilder is more than just handling its logs. I regularly have to log in to both machines to fix some issue (once every week at least); if something weird is going on, I'll find out then. Also, I get logs of all sorts mailed back on a daily and weekly basis. Those logs I do examine conspiciously. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 09:49:21PM +1100, Russell Coker wrote: On Wed, 3 Dec 2003 20:34, Artur R. Czechowski [EMAIL PROTECTED] wrote: On Wed, Dec 03, 2003 at 02:00:51PM +1100, Russell Coker wrote: I agree that smartcards would help a lot. However as has been previously suggested the cost of 1200+ smart-card readers is probably prohibitive. What about RSA tokens? This solution does not require any special hardware to connect on the client side. What is a RSA token? Device used in some internet banks. You have a device, which has only chipset, digital pad with on/off switch and display, all embedded in small case. Authentication is made using C/R algorithm: you receive a number from system, enter it into token, chipset signs it using stored RSA key, you get a number from display and use is as a password. Cheers Artur -- [...] jestem wredna, elazna mapa /Croolik/
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote: On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: On Wed, Dec 03, 2003 at 11:17:19AM +1100, Russell Coker wrote: The only way to have avoided this kernel vulnerability from day-0 of discovery/fix release would have been to be constantly upgrading to pre-release kernels. I'm starting to sound like I'm trolling for closed-source development models or something, which is not the case, Smartcards would have avoided the Debian compromise: merely having a compromised DD box would have prevented bad guy from getting on the box. Perhaps. But smartcards have a significant problem in a project such as Debian: Are you going to pay for all those smartcards plus their readers? Including any smartcards for possible future DD's? If not, I suggest we forget about this, as it won't be feasible. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote: What is a RSA token? Device used in some internet banks. You have a device, which has only chipset, digital pad with on/off switch and display, all embedded in small case. Authentication is made using C/R algorithm: you receive a number from system, enter it into token, chipset signs it using stored RSA key, you get a number from display and use is as a password. Yeah, these are good: they're cheap and I think it would have been effective at preventing this particular incident. That's an excellent idea.
The term Custom Debian Distribution (Was Re: [custom] The term flavor and encouraging work on Debian)
On Wed, 2003-12-03 at 12:17, Andreas Tille wrote: On Tue, 2 Dec 2003, Fabian Fagerholm wrote: The term suggests that the distribution is not-Debian, which is unneccessary and confusing. As non native speaker and also in general I try to avoid joining stupid naming discussions. But here is the weak part of the name we have choosen which has definitely to be clarified in an announcement of those people who invented the term. If some of the people who participated in the Debcamp Custom Distribution BOF (see http://www.debian.org/devel/debian-nonprofit/News/2003/20030717) are listening, perhaps you could elaborate? (Cc'ing Mako Hill since he was referenced as one of the driving forces behind the meeting.) It might be hard, impossible and undesirable to reverse the decision to use the term. I think the term can be correctly understood if you present it as I have in some recent postings to this list: Debian is the super-project. XYZ is a Debian subproject that produces a Custom Debian Distribution with the flavors A, B and C. A subproject is easily understood: it's an organisational structure. Basically, it's a group of people working on a subset of Debian. They coordinate via a web site and in some cases have a special mailing list. Some subprojects create Custom Debian Distributions for their particular area of interest. Upon installation of the Custom Debian Distribution, you can select between a number of flavors that set some defaults to suit a particular use. More ideas? Perhaps some of this could be intergrated into the Debian Subproject Howto as soon as some degree of consensus has been reached. (I can't find it right now with people.d.o being inaccessible.) -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:10:28PM +0100, Wouter Verhelst wrote: Are you going to pay for all those smartcards plus their readers? Including any smartcards for possible future DD's? If not, I suggest we forget about this, as it won't be feasible. I don't think the USB models cost that much (maybe $50-$100 ea. in bulk). My badge at Microsoft was my smart card. The devs themselves could pay part of the cost, with perhaps partial donations from a corporate sponsor. I think even a college student could find $50 for this. The other guys suggestion about RSA tokens was better. I think they are probably only $15-$25, because they don't connect to your PC. Anyway, feel free to forget about it. It was just a suggestion.
Re: Revival of the signed debs discussion
Hi,
[ I'm Cc-ing Werner Koch on this ]
Wouter Verhelst:
On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
Hi, Henrique de Moraes Holschuh wrote:
On Tue, 02 Dec 2003, Wouter Verhelst wrote:
So unless you have a suggestion that would solve this particular issue,
I'm afraid this idea won't work in practice.
We could verify if the gpg agent (gpa? I forget the name...) cannot do
this
over a secure channel. It should be able to, and if not, it can probably
be
taught to.
It's not that easy (basically you need to tunnel the actual
encryprion/signing function, not just the passphrase-getting).
See ssh-agent as an example.
The good thing is that people are already thinking about this.
http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html
Well, implemented as Werner suggests in that message would require me to
send the actual .deb over the line. I won't do that,
... and it doesn't make sense, since ...
As I understand it, an OpenPGP signature is an encrypted hash or
something similar of the actual data. It would be feasible if the
signature algorithm would allow for hashing the data on the remote
machine, and signing that hash locally.
... that would work. It'd probably require a few hooks within GPG
to generate a hash packet / .
Then again, we could do such things right now. Wouldn't it be more
interesting to gpg-sign md5sums of control.tar.gz and data.tar.gz?
That makes a lot of sense; you can then compare md5sums independently.
You can't directly compare detached signatures: they're timestamped and
contain random data, AFAIK.
Still, sending the to-be-signed file across the wire doesn't make sense.
Especially in the case of larger .debs, that would probably reduce the
actual signature size as well...
?? A hash is a hash, and should be independent of file size.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
REAL PROGRAMMERS don't write in Pascal, Mesa, Ada or any of those other pinko
computer science languages. Strong typing is for people with weak memories.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote: What is a RSA token? Device used in some internet banks. You have a device, which has only chipset, digital pad with on/off switch and display, all embedded in small case. Authentication is made using C/R algorithm: you receive a number from system, enter it into token, chipset signs it using stored RSA key, you get a number from display and use is as a password. The RSA SecurID tokens are a bit smarter than that; the output for a given input changes every minute. My employer uses them for remote access to their intranet; you have a fixed pin number which you enter into the card to get this minute's (6 digit) password. No reason why the pin would have to be fixed though. I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Revival of the signed debs discussion
On Wed, Dec 03, 2003 at 12:08:10PM +0100, Matthias Urlichs wrote: Wouter Verhelst: Especially in the case of larger .debs, that would probably reduce the actual signature size as well... ?? A hash is a hash, and should be independent of file size. Obviously, sorry. I don't know how I got that idea :) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: configuring lilo on package installation
On Sun, Nov 23, 2003 at 06:19:39PM +0100, Tobias Grimm wrote: Hi! I'm working on a nvram-wakeup package for a Debian based VDR distribution (c't vdr). nvram-wakeup needs a special kernel-image, that forces a shutdown on the next reboot. Normally this image is installed to /boot and a new section has to be added to lilo.conf: image = /boot/bzImage.poweroff label = PowerOff It wouldn't be a problem to modify the lilo.conf in the maintainer script, but I'm not sure if this is the way this should be done. Yes it is, it's a policy violation. What's the best way to add a section to the lilo.conf during package installation (and remove it when uninstalling)? If the lilo manager does not provide a script to manage lilo.conf, or does not provide a way to hook things into it (the answer to both question is, I believe, that it doesn't), IMHO you can only add a debconf note telling the admin what he needs to do in order to enable the package. Regards Javi signature.asc Description: Digital signature
Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
* Chad Walstrom [EMAIL PROTECTED] [031202 18:14]: I'm not following your logic, if that's what you call it. You're saying that checking the current filesystem on a daily basis is NOT a good way to verify filesystem integrity? I say it won't give you an real advantage over checking the *.md5sums files. (The only slight advantage is that it lists all file, but the disadvtage that you cannot verify your database). Update your system when you introduce a known change (a must). Check it daily (a must). What is incorrect about this policy? It will only help you to catch intruders securely, if you your check involves rebooting daily from a ro-media containing verified kernel and checksum-utilities. Not to talk about, that a database update should at least be done after booting from clear mendium without net-access and checking that the changes are correct. Otherwise it only catches intruders, hwo are to stupid to cope with system installed. (Which is the same as with installed .md5sums files) Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Bug#222450: ITP: audiolink -- makes managing and searching for music easier
Package: wnpp Severity: wishlist * Package name: audiolink Version : 0.04 Upstream Author : Amit Shah [EMAIL PROTECTED] * URL : http://audiolink.sourceforge.net/ * License : GPLv2 Description : makes managing and searching for music easier AudioLink is a tool that makes searching for music on your local storage media easier and faster. Your searches can include a variety of criteria, like male artists, female artists, band, genre, etc. . It works with MP3 files and creates a mysql database in which it stores the information about the music files. . -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux magrathea 2.6.0-test11 #1 Thu Nov 27 10:56:43 IST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 22:27:39 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: The RSA SecurID tokens are a bit smarter than that; the output for a given input changes every minute. My employer uses them for remote access to their intranet; you have a fixed pin number which you enter into the card to get this minute's (6 digit) password. No reason why the pin would have to be fixed though. I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Bug#222592: ITP: sks -- Synchronizing OpenPGP Key Server
Package: wnpp Severity: wishlist * Package name: sks Version : 1.0.5 Upstream Author : Yaron M. Minsky [EMAIL PROTECTED] * URL : http://www.nongnu.org/sks/ * License : GPL (parts are LGPL, BSD) Description : Synchronizing OpenPGP Key Server SKS is an OpenPGP key server that correctly handles all OpenPGP features defined in RFC2440 and RFC2440bis, including photoID packages and multiple subkeys. . This key server implementation uses an efficient and reliable reconciliation algorithm to keep the database in sync with other SKS servers. Additionally it can both send and receive PKS style sync emails.
Re: Revival of the signed debs discussion
Hi,
Werner Koch:
There are some minor problems because we don't just sign a hash but
need to add some more data. Creating an incomplete hash on the remote
machine is not the cleanest solution, so I have to come up with a
better way.
You're the GPG expert...
I'm also a bit concerned about MitM attacks; the hash-or-whatever which
the local side is supposed to sign should probably be encrypted with the
signer's public key, otherwise I can just replace the data packet with
something that ends up signing a totally different file. :-/
In other words, doing this isn't trivial.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Show respect for age. Drink good Scotch for a change.
Re: The term Custom Debian Distribution (Was Re: [custom] The term flavor and encouraging work on Debian)
On Wed, 3 Dec 2003, Fabian Fagerholm wrote:
It might be hard, impossible and undesirable to reverse the decision to
use the term.
Exactly.
I think the term can be correctly understood if you
present it as I have in some recent postings to this list:
Debian is the super-project.
XYZ is a Debian subproject
that produces a Custom Debian Distribution
with the flavors A, B and C.
A subproject is easily understood: it's an organisational structure.
Basically, it's a group of people working on a subset of Debian. They
coordinate via a web site and in some cases have a special mailing list.
Some subprojects create Custom Debian Distributions for their particular
area of interest. Upon installation of the Custom Debian Distribution,
you can select between a number of flavors that set some defaults to
suit a particular use.
Thanks for this clarifying words.
More ideas? Perhaps some of this could be intergrated into the Debian
Subproject Howto as soon as some degree of consensus has been reached.
(I can't find it right now with people.d.o being inaccessible.)
You might try
apt-get {source,install} subproject-howto
Kind regards
Andreas.
Re: Backport of the integer overflow in the brk system call
On Wed, 3 Dec 2003 23:06, Marc Haber [EMAIL PROTECTED] wrote: I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. For an initial order of 1200 units and the potential for other larger orders they may reconsider this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 01:06:08PM +0100, Marc Haber wrote: On Wed, 3 Dec 2003 22:27:39 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: The RSA SecurID tokens are a bit smarter than that; the output for a given input changes every minute. My employer uses them for remote access to their intranet; you have a fixed pin number which you enter into the card to get this minute's (6 digit) password. No reason why the pin would have to be fixed though. I have no idea what they cost. Also the newest ones are not exactly fit for carrying around in your wallet. They last 3 years on internal batteries. I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. That's true, but there may be similar technology available from other companies. I have no idea what the server-side part looks like, having only been an end user of the token solution. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote: [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into private mail, but your e-mail address was munged in some sort of anti-spam measure, and not trivially un-mungeable. Please consider providing information on how to demunge it in some X- header, or not using munging at all.] Heh. That's my actual email address. Fooled ya. How about including your full name somewhere in your posts too then? I find it a bit off-putting to discuss security with someone who's obscuring their identity. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Revival of the signed debs discussion
Wouter Verhelst [EMAIL PROTECTED] writes: On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote: Hi, Henrique de Moraes Holschuh wrote: On Tue, 02 Dec 2003, Wouter Verhelst wrote: So unless you have a suggestion that would solve this particular issue, I'm afraid this idea won't work in practice. We could verify if the gpg agent (gpa? I forget the name...) cannot do this over a secure channel. It should be able to, and if not, it can probably be taught to. It's not that easy (basically you need to tunnel the actual encryprion/signing function, not just the passphrase-getting). See ssh-agent as an example. The good thing is that people are already thinking about this. http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html Well, implemented as Werner suggests in that message would require me to send the actual .deb over the line. I won't do that, since I don't have the bandwidth (or, in many cases, the time to wait for the download to finish; arrakis runs behind an ADSL line, while quickstep behind my cable modem. upstream speeds aren't that fast (and I regularly handle their mails at work)). As I understand it, an OpenPGP signature is an encrypted hash or something similar of the actual data. It would be feasible if the signature algorithm would allow for hashing the data on the remote machine, and signing that hash locally. Then again, we could do such things right now. Wouldn't it be more interesting to gpg-sign md5sums of control.tar.gz and data.tar.gz? Especially in the case of larger .debs, that would probably reduce the actual signature size as well... The size being 132 bytes with only 72 bytes actual payload is small enough. But we could change what gets signed: Instead of signing the control.tar.gz + data.tar.gz cated together the list of md5sums of all files already present in the deb is signed. The md5sums list would only be a few hundert bytes so transmitting it over the network is not a problem. But it would mean one can't sign buildd uploads offline anymore, or at least not in one go. The deb has to be signed first and then a new chages file created. Only transmitting and signing a digest of the deb is allways an option if it becomes clear that splitting the gpg signing procedure (as debsisgs uses now) between the remote and local system becomes to complex. Lets see if a gpg agent can be developed that allows remote signing without transmitting the deb. MfG Goswin
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Thu, Dec 04, 2003 at 12:20:57AM +1100, Hamish Moffatt wrote: How about including your full name somewhere in your posts too then? I find it a bit off-putting to discuss security with someone who's obscuring their identity. Ha Ha Ha what a joke. I don't want to be googled for all eternity. Let me tell you a story about a job I had one time: I worked for a guy (in his basement -- don't ask) who bought your personal credit card data and other publicly available information. He would pay about $10,000 or $15,000 for lists of ~100,000-200,000 people's data. My job was to datamine it under criteria like: Give me all the people who make between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain area, and used their Visa more than 10 times on the boat within the last 6 months. We'd rank order the data, apply the filter, and maybe get 10,000 good names, which he would sell for about $140,000 to a home alarm company, who would then call you during dinner. [1] Another job I had was for a drug testing company. My job was to write the report processing system which would say You Person X have Tested Positive for Drugs A, B, and C and you are fucked. At one point in 1994 I had 40,000 people's drug test results on my 486SX-50. Just for grins I did a group by query, grouping drug frequency by a company's SIC industry code, and sorting in descending order. The most frequent people to test positive for drugs are construction workers, marijuana and cocaine. The next most frequent are school employees (probably bus drivers) testing positive for alcohol. Everything else was kind of evenly distributed. And you wonder why I am concerned with my identity!!! [1] I finally told the guy to go pound sand. I said: You'd be more useful to society if you just grow corn or something. Doing that type of work made me want to slit my wrists.
Re: Revival of the signed debs discussion
Matthias Urlichs [EMAIL PROTECTED] writes: Hi, Werner Koch: There are some minor problems because we don't just sign a hash but need to add some more data. Creating an incomplete hash on the remote machine is not the cleanest solution, so I have to come up with a better way. You're the GPG expert... I'm also a bit concerned about MitM attacks; the hash-or-whatever which the local side is supposed to sign should probably be encrypted with the signer's public key, otherwise I can just replace the data packet with something that ends up signing a totally different file. :-/ In other words, doing this isn't trivial. Assume you have a secure connection. A ssh connection will be more secure than the mail being send around now. Anyone could do a MitM attack on the changes files being mailed, get his own packages changes file signed, upload the debs and hope noone notices the build didn't actually upload its deb. Encrypting the digest with the public key before sending would only ensure only the recipient can read it, which is rather pointless for pretty random bits. You could encrypt or sign it with the buildds gpg key to ensure the origin of the message. Anything short of a compromised buildd would be save and a compromised buildd would be fatal whatever method is used. MfG Goswin
Re: configuring lilo on package installation
Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= [EMAIL PROTECTED] writes: On Sun, Nov 23, 2003 at 06:19:39PM +0100, Tobias Grimm wrote: Hi! I'm working on a nvram-wakeup package for a Debian based VDR distribution (c't vdr). nvram-wakeup needs a special kernel-image, that forces a shutdown on the next reboot. Normally this image is installed to /boot and a new section has to be added to lilo.conf: image = /boot/bzImage.poweroff label = PowerOff It wouldn't be a problem to modify the lilo.conf in the maintainer script, but I'm not sure if this is the way this should be done. Yes it is, it's a policy violation. What's the best way to add a section to the lilo.conf during package installation (and remove it when uninstalling)? If the lilo manager does not provide a script to manage lilo.conf, or does not provide a way to hook things into it (the answer to both question is, I believe, that it doesn't), IMHO you can only add a debconf note telling the admin what he needs to do in order to enable the package. One can dpkg-divert lilo with a script that runs the real lilo with an alternate config file. But thats realy ugly and only works for one package at a time. MfG Goswin
Re: Backport of the integer overflow in the brk system call
On Thu, 4 Dec 2003 00:19:36 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: On Wed, Dec 03, 2003 at 01:06:08PM +0100, Marc Haber wrote: I seriously doubt that the server-side software is DFSG-free. The only Linux Agent that is available from rsa.com is for RedHat 7.3, and I would be astonished if it were available in source code form. That's true, but there may be similar technology available from other companies. I have no idea what the server-side part looks like, having only been an end user of the token solution. I have only taken a perfunctory look at the web site, and the server-side looks like a PAM plugin for the RSA product. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Revival of the signed debs discussion
Hi,
Werner Koch:
On Wed, 3 Dec 2003 13:26:02 +0100, Matthias Urlichs said:
the local side is supposed to sign should probably be encrypted with the
signer's public key, otherwise I can just replace the data packet with
something that ends up signing a totally different file. :-/
And if I do that, I could also sign the file right at the remote
machine because the (or some) signature key must be available over
there ;-)
Ouch. You're obviously right. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The day advanced as if to light some work of mine; it was morning,
and lo! now it is evening, and nothing memorable is accomplished.
-- H.D. Thoreau
Re: The term Custom Debian Distribution (Was Re: [custom] The term flavor and encouraging work on Debian)
On Wed, Dec 03, 2003 at 01:24:24PM +0200, Fabian Fagerholm wrote: If some of the people who participated in the Debcamp Custom Distribution BOF (see http://www.debian.org/devel/debian-nonprofit/News/2003/20030717) are listening, perhaps you could elaborate? (Cc'ing Mako Hill since he was referenced as one of the driving forces behind the meeting.) It might be hard, impossible and undesirable to reverse the decision to use the term. I think the term can be correctly understood if you present it as I have in some recent postings to this list: Debian is the super-project. XYZ is a Debian subproject that produces a Custom Debian Distribution with the flavors A, B and C. Right. Your other posts seems well informed. Subprojects is already defined for us (see http://www.debian.org/devel/ for an example of one place). Debian-NP is clearly a subproject as is Debian-Med and the IPv6 project. If you apt-get install the subproject-howto you will get something talking *only* about creating a custom Debian-distribution -- not about creating a subproject for any other sort of work. The folks at the BOF saw a real lack of interaction between the people making custom distributions and we attributed this, in part, to the fact that we didn't have a single concept around which identify and say, yeah, that person is doing the same thing as me, we should work together. The flavors people were not working with the metadistros people and the subproject people where on their own. We thought Custom Debian Distribution (and a [custom] tag in emails to -devel until a list is created) both referenced our relationship to Debian (we're inside) and described what we were trying to do in a way that was not so restrictive that it couldn't refer to multiple technologies but not so broad that it would apply to projects with very different types of goals. I think we left with the idea that flavors or metadistros and the like may still describe *technologies* or methods which one could use to achieve a Custom Distro. I think this is in line with what AJ, yourself, and others have said -- which is nice. :) More ideas? Perhaps some of this could be intergrated into the Debian Subproject Howto as soon as some degree of consensus has been reached. (I can't find it right now with people.d.o being inaccessible.) I think it absolutely should. I also think the HOWTO should be renamed or expanded in scope to bring it into alignment with the consensus that seems to be coalescing around these issues. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.yukidoke.org/ pgpOrscPgu7VS.pgp Description: PGP signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:24:50AM -0800, Tom wrote: On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: If something could have prevented something that actually happened, I say go for it. Oh, one last thing: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? Hahahahahahahaha Share the crack. plonk -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote: Share the crack. In my experience kids in college and right out tend to freak out over the thought of having to spend a few dollars of disposable income, because they don't have any :-) Hey, laugh if you want, most organizations have dues, it's not unprecedented in human history :-)
Re: [RFC] adding system users: which is the best way??
Steve Greenland [EMAIL PROTECTED] wrote: [...] I think the idea of a namespace for usernames used by packages is a good idea, but rather than debian-, we should take this to the LSB folk, so that we can get it done once. The problem with this is time. I need to add a system-user (for exim4) _now_. Shall I go for namespace, and if yes which one? _debian-exim, debian-dexim, DEB-exim? cu and- wondering whether he should actually subscribe to another ml. -reas
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 05:42:20AM -0800, Tom wrote: Let me tell you a story about a job I had one time: I worked for a guy (in his basement -- don't ask) who bought your personal credit card data and other publicly available information. He would pay about $10,000 or $15,000 for lists of ~100,000-200,000 people's data. My job was to datamine it under criteria like: Give me all the people who make between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain area, and used their Visa more than 10 times on the boat within the last 6 months. We'd rank order the data, apply the filter, and maybe get 10,000 good names, which he would sell for about $140,000 to a home alarm company, who would then call you during dinner. [1] So you've aided telemarketers and worked for Microsoft? Is your last name Darkness, middle name Prince of? -- gram signature.asc Description: Digital signature
Re: [custom] Debian Enterprise - a Custom Debian Distribution
On December 1, 2003 07:05 pm, Enrico Zini wrote: On Mon, Dec 01, 2003 at 02:33:57PM -0600, Chad Walstrom wrote: - GNU ERP software project ?name? GNU Enterprise (gnue) http://www.gnue.org/ I've just learnt of Cubit from South Africa: http://www.cubit.co.za/ Is it free software? They don't seem to provide a link to the full text of their license, it sounds free according to their license summary but I also see the statement Cubit has only a very small yearly license fee and no purchase cost. -- Fraser Campbell [EMAIL PROTECTED] http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux
Bug#222630: ext2 is the wrong default for partconf/create-filesystem
I think the reason for that is because on old BF days disk space was expensive (so lost 32MB for a journal file ou more than that would be a considerable lost). Joey Hess [EMAIL PROTECTED] escreveu em Sun, 30 Nov 2003 21:43:54 -0500: Package: partconf Severity: normal Most users will want a journaling filesystem, and ext3 would be a good choice for the default filesystem type, but the current default, ext2, is not a very good choice. I suggest to s/2/3 in the Default field of the partconf/create-filesystem template. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux dragon 2.4.22 #1 Sun Oct 12 15:11:10 EDT 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US -- see shy jo --- Gleydson Mazioli da Silva [EMAIL PROTECTED] [EMAIL PROTECTED] Negligência: Nome que se dá, no colégio, à burrice das crianças ricas. pgpquQdgm9Jab.pgp Description: PGP signature
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 09:06:07AM -0600, Graham Wilson wrote: So you've aided telemarketers and worked for Microsoft? Is your last name Darkness, middle name Prince of? Satan fell because he wanted to know. So do I. I'm a contrarian. I believe the opposite of whatever I'm confronted with at the moment. Evil is when you look around your life and say: man, I gotta get some new friends. :-)
exim4-config and exim4-base installed on systems with non-exim-MTA
Hi, as co-maintainer for the exim4-packages, I have noticed an issue with dselect. Currently, exim4 is the default MTA, and exim4, exim4-base, exim4-config and exim4-daemon-light are Priority: important, while exim4-daemon-light provides mail-transport-agent. The exact package dependencies can be seen in the archive. This causes dselect to install exim4-base and exim4-config on a system that has some other (non-exim) MTA installed, which is a bad thing. I have discussed this with Andreas, and we didn't find a solution, since the exim4-packages need to be installed and configured in a certain order to be operational. Both of us are not adept in package dependency declaration, so I would like to ask the experts how to solve this problem. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: exim4-config and exim4-base installed on systems with non-exim-MTA
On Wed, Dec 03, 2003 at 04:41:00PM +0100, Marc Haber wrote: as co-maintainer for the exim4-packages, I have noticed an issue with dselect. Currently, exim4 is the default MTA, and exim4, exim4-base, exim4-config and exim4-daemon-light are Priority: important, while exim4-daemon-light provides mail-transport-agent. The exact package dependencies can be seen in the archive. What are they, exactly, and why are they that way? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgphcwC6tQbhF.pgp Description: PGP signature
Two different libpng2_1.0.12-3.woody.3_i386.deb?
file=main/libp/libpng/libpng2_1.0.12-3.woody.3_i386.deb wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file wget -q -O 2.deb http://security.debian.org/pool/updates/$file diff 1.deb 2.deb Binary files 1.deb and 2.deb differ How could this happen? Should I worry about it?
Re: exim4-config and exim4-base installed on systems with non-exim-MTA
On Thu, Dec 04, 2003 at 02:15:30AM +1000, Anthony Towns wrote: On Wed, Dec 03, 2003 at 04:41:00PM +0100, Marc Haber wrote: as co-maintainer for the exim4-packages, I have noticed an issue with dselect. Currently, exim4 is the default MTA, and exim4, exim4-base, exim4-config and exim4-daemon-light are Priority: important, while exim4-daemon-light provides mail-transport-agent. The exact package dependencies can be seen in the archive. What are they, exactly, and why are they that way? exim4 is a metapackage that depends on the other three and is not hit by the problem. The rest is a straighforward chain. With as depends on: daemon -base -config. other possible dependencies would be: daemon -config -base or daemon -base `-- -config The daemon-packages provide/conflict/replaces MTA. The main point is that the daemon is started by its own postinst and therefore it requires ATM -base to be unpacked (init-script) and -config to be configured. Afaict starting/stopping the the daemon in its own postinst/prerm is really the only correct thing to do as it needs to be restarted when only daemon is upgraded or when you exchange daemon-light for daemon-heavy. cu andreas
Re: development environment question
On Wed, 2003-12-03 at 18:36, bruce wrote: hi... I was talking with Ian Murdock yesterday, and he suggested I pose the question to this group. We're interested in creating a development environment that would allow open source applications to be created. The development environment would go beyond simply providing project management functions (ala sourceforge.net) but to actually allowing developers to build/create/test their applications within our network. Users would be able to add/modify applications on the test servers to suit their needs. Such a network would have to be carefully developed, given the inherent security issues. The issue we're facing, is how would you go about constructing such an environment. Does anyone have any pointers to information/sites regarding this issue? Does anyone have expertise regarding the construction/development of this kind of environment? I kind of thought that given what Debian has put together with it's development environment, that there might be people on this list who might be able to provide some pointers. All reasonable pointers/assistance will be helpful. Thanks Bruce Douglas [EMAIL PROTECTED] (925) 866-2790 Hi Bruce, I don't want to disappoint you, but as with all IT projects, you need to specify a very specific goal that you want to achieve. Your goal, allow open source applications to be created and allowing developers to build/create/test their applications within our network. Users would be able to add/modify applications on the test servers to suit their needs doesn't sound very aimed toward something. Given the requirements for application development, a lonely place for writing and a clean environment for testing, I don't think you are going to achieve much. Separated testing environments with free access to the internet to the outside, look like an awfully inviting target for people with not so nice intentions (spammers, virus distributers, port scanners etc.) Good luck, hope you make something of your idea. Sincerely, Jan.
Re: [custom] Debian Enterprise - policies
On Wed, 03 Dec 2003 15:01:09 +1100, Zenaan Harkness wrote: (Really should read ahead further ... here are more, and all laid out together) * DFSG Free Software only (I know this one will get debated, but this is the whole point of Debian Enterprise - if you want proprietary software, go buy Red Hat or SUSE/Novell). This goes without saying. If it's under the Debian name, it should comply w/ the various Debian policies. * Specifically targetting For-Profit entities (vs Debian-NP) Is this really a goal? While we're not specifically targeting non-profit entities, we're not going to exclude them, either; especially if they have infrastructure similar to a standard for-profit company. Non-profits need their oracle, too. ;) * 100% Debian (Social Contract, DFSG, policies + procedures) * LSB compliance I think LSB compliance is one of the most important things listed (aside from standard stuff like policy compliance). We want commercial software vendors to supply binaries that adhere to the LSB; whether distributed in deb, rpm, or tarball format. Furthermore, we want to convince commercial software vendors that working within the LSB is more important than working within Debian. A company may certify their software to work w/ DE (or a DE flavor); we should convince them to certify software to work w/ all LSB-compliant distributions. This allows companies to not limit themselves to DE, or a subset of DE flavors, but all of Debian (and other LSB-compliant distributions). * Official statement as to support of Freedesktop.org standards * Common Criteria (not until we're big enough) * OpenCOE (the COE folks had to wedge _apt_ into Red Hat to get it to work to their satisfaction) * we have a FIPS 140 certification for OpenSSL * Other standards ??
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 01:54:22PM +1100, Matthew Palmer wrote: Nov 28 22:39 Linux 2.4.23 released ^ Bernd is correct, though - if the machines had been running 2.4.23, they wouldn't have been vulnerable. The fact that it was impossible to do so doesn't enter into the equation when you're working from blind assertions. g Hehe, well I am sorry. I had the impression 2.4.23 was older. Should have checked my facts. BTW: I do have checked the kernel version of the major distros, all ship newer kernels than debian (if you look at the upstream version). However I do not know how reliable dostrowatch is, for comparision. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Backport of the integer overflow in the brk system call
* Russell Coker ([EMAIL PROTECTED]) [031203 04:03]: I have sent a message to Werner asking if the GPG smart-card device could be re-implemented with a USB interface. I think that a USB dongle with GPG technology would be a good option as most developer's machines already have USB support. as discussed in depth in an earlier c't magazine (german) usb is not a save bus to use for security relevant applications, since it allows for recording and backplaying of command sequences.
Re: debsums for maintainer scripts
On Mon, 1 Dec 2003 19:22:44 -0200, Henrique de Moraes Holschuh [EMAIL PROTECTED] said: On Mon, 01 Dec 2003, Thomas Viehmann wrote: Henrique de Moraes Holschuh wrote: On Mon, 01 Dec 2003, christophe barbe wrote: Before mass bug-filling, it would be necessary to make it mandatory which unfortunately is not the case right now afaik. Deployment plan for md5sums everywhere: At ~600 affected source packages, this seems hardly feasible. It is feasible. You just to care about it enough, and you certainly don't have to do it alone, or in one go. Otherwise, it simply won't happen, unless about 90% of the packages or so aready use md5sums. At that figure, you have some changes of passing a policy of 'must', and you are guaranteed to get a 'should' to be approved IMHO. Before we make such a push, we should at least ensure that it is something we really want to do. I think locally generated checksums are a better solution. manoj -- There are three schools of magic. One: State a tautology, then ring the changes on its corollaries; that's philosophy. Two: Record many facts. Try to find a pattern. Then make a wrong guess at the next fact; that's science. Three: Be aware that you live in a malevolent Universe controlled by Murphy's Law, sometimes offset by Brewster's Factor; that's engineering. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: [custom] Debian Enterprise - packages
On Wed, 2003-12-03 at 05:49, John Goerzen wrote: * Office Suite - OpenOffice (there's no other near as feature complete) And OpenOffice is the only one that runs on only two -- yes, two -- architectures that Debian supports. You missed two. OOo is available on i386, powerpc, sparc and s390. Chris
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
I demand that Tom may or may not have written... On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote: Share the crack. In my experience kids in college and right out tend to freak out over the thought of having to spend a few dollars of disposable income, because they don't have any :-) Some of us have to *buy* them before we can spend them ;-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Oh, sarge too... This was the most unkind cut of all.
Re: [custom] Debian Enterprise - flavors
Zenaan Harkness said on Wed, Dec 03, 2003 at 02:58:18PM +1100: Flavours (and sub-flavours/ tasks/ yadda) is as good a place to start as any. So here are some proposed flavours: - Enterprise (base packages and more neutral config) - Enterprise Desktop - with sub-flavours of: - Secretary Desktop - Presentation Client (OO Presenter, multimedia, flash) - Developer Desktop (all build-depends of all flavours, as a start) - Enterprise Fileserver - Enterprise Webserver - Enterprise Auth Server - Enterprise Departmental Server (combines File, Web + Auth) - Enterprise Firewall - Enterprise SCM Server - Enterprise Router - Enterprise Thin Client Something to keep in mind that most of the above could be handled by exactly the same software loadout. For example: There is no difference between Desktop, Fileserver, Webserver, Auth Server loadouts that matters; you just turn off the services by default and let the customization process turn on the services that matter for that role. It doesn't matter if the webserver has openoffice installed; it's just a few bits on disk. It might be worth reading http://www.infrastructures.org/papers/bootstrap/bootstrap.html before getting flavour happy. M pgpduCDZGTL4W.pgp Description: PGP signature
Re: [custom] The term flavor and encouraging work on Debian
On Wed, 3 Dec 2003, Andreas Tille wrote: On Wed, 3 Dec 2003, Fabian Fagerholm wrote: In my view (as I said), it would be logical to name a further subdivision of that product flavor. I like this interpretation of the term flavor and it would be easily applicable for Debian-Med to flavors like: - Medical practice - Medical research [snip] Just a suggestion on naming: Due to the unclear connotations, there is a great deal of confusion over the terms internal project, subproject, flavor, custom Debian distribution and the like. To clarify my own thinking, I started using just subset and mutation instead. To my mind, the difference is whether a given collection of packages aims to be straightforwardly upgradable to a full Debian (IOW, whether it can peacefully coexist with any number of packages from Debian proper). If yes, it's a subset. If no, it's a mutation. Debian-Jr, Debian-NP, Debian-Lex, Debian-Med are all subsets. Adamantix and Knoppix are mutations. Subsets can also have subsets, or a subset may even come from the confluence of other subsets, so there is no need to name one level a custom Debian distro and another level a flavor. My EUR 0.02, Istvan
Re: debsums for maintainer scripts
On Mon, 1 Dec 2003 18:08:28 +0100, Eduard Bloch [EMAIL PROTECTED] said: AFAICS the only way to verify the contents of maintainer scripts automaticaly is to have the binary package, verify its contents via .changes or Release/Packages path, extract it and compare the files. Too complicated. umm, not if it is automated at install time, when the package is present already. I would like to see the following things happen: - current md5sums file in control.tar.gz should contain checksums of really all files Hard to do for conffiles. Now, if the md5sums were generated at install time, you could checksum my locally modified conffile (even if I did not accept the maintainers changes). The md5sums stored for conffiles currently are rarely any good, since the files are often modified by the admin. - a signature of the md5sums file should be stored either in control.tar.gz or in the ar file itself So you have to download the package itself to check the contents of the md5sum fule? Why not generate the md5sums at this point anyway? - new dpkg version should pickup the signature files and store them either in /var/lib/dpkg/info or in some alternative directory Or you could sign the newly generated md5sum files at install time, complete with the checksums of the locally modified conffiles, and not have to depend on knowing the key of the persons producing the Packages file. - modify debsums to check the signature as well as maintainer scripts' checksums ok. manoj -- I have a theory that it's impossible to prove anything, but I can't prove it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: UserLinux white paper
On Wed, Dec 03, 2003 at 04:36:18PM +1100, Zenaan Harkness wrote: How many financials implementations are ultimately needed - really only one, perhaps customized for vertical markets. A healthy market requires competition. And different companies have very different needs. The IT Infrastructure is indeed the only last field where Enterprises can differ, today. This is the Proprietary software model, with artificial, government imposed (via copyright laws) monopolies, resulting in customer lock-in and price maximization. I dont see a monopol, at least no government imposed. This is not a properly free market economy. The monopolies are artificially imposed, not natural. Well, I dont think it is correct to asume that Free Software can be the model for all Software Business. Someone has to pay for the work needed, after all. And somebody has to get payed, which is more important! (Yes I known, Free is Free as in free speach). Free Software is one possible business model, as long as it is not priceless. Customer lock-ins are more uncommon with Free Software (however, even if you have the source code to your FI, you wont change your software rovider easyly). Free Software clearly and evidently redifines *within the current (legal, financial) system* the way to a Free Market Economy. Hmm.. the above sentence looks good, I wonder what it means? We will see profits of some ISVs fall, we will see others disappear altogether. We will see new organisations take hold in this new free market - predominantly services-based organizations. It does not look that way, if you look on the current market, but I might be wrong. Looking at the figures of a typical ISV, most of them (unless they manage to do a large share if OEM business) earn more than 50% of their money by services. It is already the case, that service is the main focus in the business. You do not sell software, you solve problems. (You sell solutions, like Ted put it) Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: [custom] The term flavor and encouraging work on Debian
On Wed, 2003-12-03 at 01:32, Zenaan Harkness wrote: Debian is the super-project. Debian Enterprise is a Debian Subproject that creates a Custom Debian Distribution, Subproject and custom debian distribution, here, are the same thing. No point officially having two terms. CDD is a term that I think is intended to be a little more expansive than subproject, so I think that's more applicable for this level of naming... When the term Custom Debian Distribution was chosen, the rationale was that there is a need to differentiate between subprojects that aim to create a special version of Debian, and subprojects that do other things, such as IPV6 or the technical committee. So, I interpret that as meaning that a subproject is an abstract, organisational thing (how it manifests itself is another matter) and a Custom Debian Distribution is the concrete product put together by a subproject. In my view (as I said), it would be logical to name a further subdivision of that product flavor. Correct depending on your view. But it is also true that Debian GNU/Linux is an original, of which Debian Enterprise is a customization - and this is the useful distinction in this case. Ok. Semantics, of course, but that's what's being discussed here. :) I just think Custom Debian Distribution is not a very innovative phrase, it is too general to instantly give someone an idea of what it's about, and on top of all, it's quite long. Compare with package pool -- anyone with decent knowledge of the English language, and who knows what a package is, will instantly see the idea. I think flavor fits into the same category. -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Revival of the signed debs discussion
Bernd Eckenfels [EMAIL PROTECTED] writes: On Wed, Dec 03, 2003 at 03:17:20AM +0100, Goswin von Brederlow wrote: What the admins signature can gives us is a trusted timestamp and another pair of eyes reading the changes files. Well, a trusted timestamp can be added/required by a third party. No need to bother a build admin with signing of packages he cannot verify. Just make a small web service which is receiving an packagename,version,hash string and answer with a signed timestamp. There are even services like that out there on the net. If there is no person sitting there signing it manually its useless. The buildd admin is already signing every changes file before upload so he is the logical person for signing debs too. Don't get me wrong, I'm all for an gpg key on the buildd to sign every deb. Not as replacement to at least one person glancing over the result but as an extra measure. How often has this person glance over the results? As I understand debian build daemons run unattended and build continously. Correct me when I am wrong here. But if I asume righ, I dont want to lose that processing speed, especially since it can be easyly compensated with 3rd party timestamps. In theory every build log is read. In praxis I believe all buildd admins scroll through the log and look for some obvious signs of errors before signing. I don't expect them to read a 17 MB logfile line by line for example. But even without reading having an actual person handling the signing has advantages. In case a buildd is compromised the signing still isn't. The attacker can't start and upload 500 backdoor packages pretending to be something else without raising red flags. Also failures in the buildd behaviour have to be cought, like building empty debs all of a sudden. A quick glance at the package contents listed in the build log will detect that. MfG Goswin
Re: [custom] Debian Enterprise - packages
On Wed, 03 Dec 2003 14:45:51 +1100, Zenaan Harkness wrote: As per the recommendations from Bruce Perens' User Linux paper http://userlinux.com/white_paper.html, this thread is to discuss the applications within the bounded set of Debian Enterprise/ User Linux. I think discussing the favorite applications, at this point, is a bit premature. Debian Enterprise (DE) should be concentrating on the framework that will make flavors possible. There is much that remains to be done on the technical level (kernels, a distribution that is up-to-date enough that companies will _want_ to use it, an installer, etc). Deciding what applications to supply isn't of much use right now (especially given the rate of development of some; mozilla-firebird may be a good choice now, but what about when epiphany or another alternative becomes the better browser?). Remember the original goals that DE is attempting to solve. Current Debian-using companies must maintain their own package backports, kernels, and so on. Deciding what browser we will default to, while possibly helping in standardization, is a long ways off. In order for DE to become useful, we must cater to companies (not the other way around). Thus, we should build out the infrastructure enough so that DE, by itself, is installable and useable. At that point, we can start worrying about what flavors will contain what software. The bounded set will depend on the flavour. So first comes proposed flavours (and sub-flavours/ tasks/ yadda) - see previous email/ thread. Here are some initial (obviously debatable and incomplete) selections to start out the bounded-apps conversation: * Web Browser - Mozilla-Firebird I've used Mozilla, Galeon in its day, more recently Epiphany, and the last few months Moz-Firebird. It is simply the simplest (and in my opinion best) of the crop. * Web Server - Apache 2.0 (let's get with the times) * Open SSH Implementation - OpenSSH (much more active that gnu version) * Office Suite - OpenOffice (there's no other near as feature complete) * Scripting Language - Python (no one will debate this one :) - I have never used, only read (plenty) about Python, and I'm not personally too sure about this white space thing, but from what I hear about it (quite consistently) eventually feeling more natural than anything else, I am inclined to believe this really is the case. My experience with Java (after C/C++) was sort of like that, and if Python is more so, then I think it could be closest to the next VB replacement
Install Images
Is there anywhere i can download debian-installer beta images (im getting a new laptop tommorow), prefereably with support for reiserfs filesystems? Gluck still isnt working and i cant seem to find mirrors anywhere. Thanks Tom -- ^__^| Tom Badran (oo)\__ | Imperial College (__)\ )\/\| Department of Computing ||w || --- || ||| Using Debian SID pgpg1D2FLjlBS.pgp Description: signature
Re: apt-rpm article -- the features we don't have
Hamish Moffatt [EMAIL PROTECTED] writes: On Tue, Dec 02, 2003 at 02:10:56PM +, Jonathan Dowland wrote: On Mon, Dec 01, 2003 at 07:06:41PM -0500, Joey Hess wrote: Similarly, to check the build depends of a source package file: apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm Should this be the job of apt-get? Fetching a list of build-depends is a similar job to that performed by apt-cache for other fields. I always associate apt-get with installing and removing packages. Yes, and apt-get build-dep somesourcepackage does install the necessary build-deps, so this fits right in. apt-get build-deb foo-version.dsc would be nice when building a package with changed build-depends (compared to what Sources.gz lists). Most of the time the ones mentioned in Sources work though and debuild will show the rest. MfG Goswin
Re: INSTALL-REPORT
On Wednesday 03 December 2003 19:33, Joshua Kwan wrote: On Wed, Dec 03, 2003 at 09:22:14AM +0100, Werner Wobrowsky wrote: Debian Installer sarge-i386-bussinescard.iso, httP://freedesktop.or/ Cool, but... FreeBSD 5.1-RELEASE-p11 #0: Thu Nov 27 15:07:08 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEW I didn't know the sarge ISOs supported Debian/FreeBSD. :) Wrong dmesg? Hehe not only that, he seems to have marked the whole dmesg and pasted it into the shell again, producing lots and lots of shell error messages. Funny thing :-) that's why it is a good idea to double-check the stuff you mail, especially when it goes to a high volume mailing list ... you could look a bit stupid. Tom P.S.: in the pasted part: $ FreeBSD 5.1-RELEASE-p11 #0: Thu Nov 27 15:07:08 CET 2003 FreeBSD: not found :-)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
AKL. Mantas Kriauciunas [EMAIL PROTECTED] writes: Hi, Debian has a usability problem - it's hard to start lots of programs, installed from debian packages, because simple users just can't find them in menu. Standart debian menu entry isn't good solution for user-friendly desktops, like Gnome and KDE, because debian menu isn't intuitive (for example there are no icons for categories) and there are no possibility to translate debian menu entry. Solution is to add freedesktop.org standartized menu entry for programs, which could be started from menu (for example there is no meaning to start apt-get tool from menu). Then users of modern desktops will be happy, because they can easily find how to start installed applications - menu entries will be localized and will be in right place. Why I'm writing this letter instead simply filling bugs on packages? ... Maybe debian developers should improve debian package making standards (Debian policy) and recommend to add Gnome/Kde menu entry for all packages, which have Debian menu entry ? Then maintainers will include .desktop files, at least after bugreports :) I'm not sure that's a good idea. I'm using Gnome and I'd like to keep a simple applications' menu, not having hundred entries like in my debian's menu. Having too many entries in a menu is an usability problem imho (it's very annoying to search an item in the middle of long menus). If you are using non KDE/Gnome apps you should perhaps add some launchers in the desktop for them ? I've added the gnome/kde in the Cc: field because I think it's rather a desktop's problem than a mentors/devel problem. Cheers, Sebastien Bacher
Re: Install Images
On Wednesday 03 December 2003 18:12, Andreas Metzler wrote: http://freedesktop.org/~daniel/d-i/ cu andreas You star ;) Thanks Tom -- ^__^| Tom Badran (oo)\__ | Imperial College (__)\ )\/\| Department of Computing ||w || --- || ||| Using Debian SID pgpQ49PglrOcI.pgp Description: signature
Re: Revival of the signed debs discussion
On Wed, 3 Dec 2003 12:08:10 +0100, Matthias Urlichs said: signature algorithm would allow for hashing the data on the remote machine, and signing that hash locally. ... that would work. It'd probably require a few hooks within GPG to generate a hash packet / . Since I moved my actual development to faster machines I now always need to copy the tarballs to the box where I can sign them and this is not very convenient. Obviously, I thought about such a solution too. There are some minor problems because we don't just sign a hash but need to add some more data. Creating an incomplete hash on the remote machine is not the cleanest solution, so I have to come up with a better way. Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org
Re: Two different libpng2_1.0.12-3.woody.3_i386.deb?
On Wed, Dec 03, 2003 at 05:44:36PM +0100, Santiago Vila wrote: file=main/libp/libpng/libpng2_1.0.12-3.woody.3_i386.deb wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file wget -q -O 2.deb http://security.debian.org/pool/updates/$file diff 1.deb 2.deb Binary files 1.deb and 2.deb differ $ dpkg -x 1.deb 1 ; dpkg -x 2.deb 2 $ diff -ur 1 2 Binary files 1/usr/share/doc/libpng2/changelog.Debian.gz and 2/usr/share/doc/libpng2/changelog.Debian.gz differ $ zdiff -qs */usr/share/doc/libpng2/changelog.Debian.gz Files - and /tmp/changelogDebian.gz.10985 are identical So, only the gzip compression on the changelog is different... which means that both packages are created independently from the same source, with the same resulting binaries etc, only apparently using different versions of gzip and/or different default options for gzip. How could this happen? Should I worry about it? Very strange, maybe it has something to do with them being security-team NMU's, one is build by security team, the other by the maintainer. Should you worry? I don't know, depends on wether it's normal that two different builds circulate on offical archives... --Jeroen -- Jeroen van Wolffelaar +31-30-253 4499 [EMAIL PROTECTED] http://Jeroen.A-Eskwadraat.nl
Re: Revival of the signed debs discussion
On Wed, Dec 03, 2003 at 06:43:18AM +0100, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote: But this kind of tampering _can_ be checked by apt before installing the deb simply by adding a signature verifyer into the DPkg::Pre-Install-Pkgs config option, the same mechanism apt-listchanges already uses to display only the new section of the changelog. Indeed, apt can do a lot better, and is very close to doing so. See #203741. The assumption was that the archive was compromised but the Release.gpg file changed and resigned. Who was assuming this? At any rate, protecting the secret key is of course the weakest link in any public key cryptosystem, and I don't see what that has to do with apt. #203741 is about checking the Release.gpg chain of trust or is there more hidden in all the mails. Yes, that is what it is about. Did the BTS reoder the mails, there don't seem to follow a locigal discussion. Haven't bothered to check the timestamps though. Messages from discussions in other fora (including private mail) were later copied to the BTS. -- - mdz
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, 2003-12-03 at 20:15, Herbert Xu wrote: AKL. Mantas Kriauciunas [EMAIL PROTECTED] wrote: Solution is to add freedesktop.org standartized menu entry for programs, which could be started from menu (for example there is no meaning to start apt-get tool from menu). Then users of modern desktops will be happy, because they can easily find how to start installed applications - menu entries will be localized and will be in right place. If the Debian menu system can't represent what you want, then we should either extend it so that it does, or get rid of it. It makes no sense to support two sets of menu entries throughout the distribution. I agree. I would like to see .desktop standard adopted. There have been a few threads I have seen so far, and there seems to be some level of resistance to the idea. I think if too many applications in menu or wanting simple menu is a different problem entirely. Once you know where to find apps, you still have too many. At the moment it's doubly complex, and that's plain silly! imho of course zen -- Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/ * Homepage: http://homepages.ihug.com.au/~zenaan/ * PGP Key: http://homepages.ihug.com.au/~zenaan/zen.asc * Please respect the confidentiality of this email as sensibly warranted.
Re: The term Custom Debian Distribution (Was Re: [custom] The term flavor and encouraging work on Debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-12-03 12:24, Fabian Fagerholm wrote: On Wed, 2003-12-03 at 12:17, Andreas Tille wrote: On Tue, 2 Dec 2003, Fabian Fagerholm wrote: The term suggests that the distribution is not-Debian, which is unneccessary and confusing. As non native speaker and also in general I try to avoid joining stupid naming discussions. But here is the weak part of the name we have choosen which has definitely to be clarified in an announcement of those people who invented the term. If some of the people who participated in the Debcamp Custom Distribution BOF (see http://www.debian.org/devel/debian-nonprofit/News/2003/20030717) are listening, perhaps you could elaborate? (Cc'ing Mako Hill since he was referenced as one of the driving forces behind the meeting.) hm, I've added a definition to the wiki: A Custom Debian Distribution (CDD) is a version of Debian that is tailored for a particular situation/target group out-of-the-box. Any changes necessary to Debian to support this particular situation/target group arge merged back into Debian whenever possible, improving Debian as a whole. - -- Cheers, cobaco 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zdCV5ihPJ4ZiSrsRAsbLAJ9DdvJr/UQyZlIA0hAQgfu9b/gdowCglNOb vJDtVz2E2aHumHDpKmxSjHc= =CIIJ -END PGP SIGNATURE-
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
AKL. Mantas Kriauciunas wrote:
Herbert Xu: Please discuss this on debian-devel before filing further
bugs.
IMHO, there's no need to discuss this to death -- .desktop files make
sense, therefore packages should supply them. There's no sane way to ask
maintainers to do so except to file bugs, therefore bugs should be filed,
and that's all there is to it.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The seven deadly sins ... Food, clothing, firing, rent, taxes, respectability
and children. Nothing can lift those seven milestones from man's neck but
money; and the spirit cannot soar until the milestones are lifted.
-- George Bernard Shaw
Re: Revival of the signed debs discussion
Anthony Towns aj@azure.humbug.org.au writes: On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote: You change the contents of the compromised Packages file, so that Package: bash is accompanied by Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb which contains a perfectly valid .deb file, signed by a DD, that has nothing whatsoever to do with bash. AFAIK, apt does not sanity check the relationship between package names and filenames (and it's not obvious that this should be part of its responsibilities), and dpkg only gets a list of .debs to install once they've been downloaded. Problem is that apt runs: Not realy a problem, a benefit in this case. # dpkg -i vulnerable-ident-server_1.0-1_i386.deb # dpkg --configure bash the latter will generally give you an error, and for remote exploits, just unpacking the vulnerable software isn't enough. It's probably fine for local exploits, but you'd have to be on your toes. You get an error. Its a bit late in the process as it is now but for me red flags would rise, sirens start screaming, the internet connection starts a 60 second hardware cut countdown :) Getting apt to downgrade a package you've already got installed is more straightforward; although apt-get dist-upgrade; apt-get dist-upgrade will keep trying to download the same deb then. Yeah, as shown version mismatches don't show up suspiciously. One has to read the output carefully to detect those. Fat chance when doing a dist-upgrade of 300 debs. That is what you ment, a older package claiming to be newer, right? Getting apt to upgrade a package you've already got installed to something newer that's vulnerable isn't detectable, but will usually need a newer libc6, which is a good warning sign. If you upgrade you probably want a newer version. Making sure you don't install a vulnerable version (be it a faked or real package doesn't much matter) is your own job. Faking the newest version to be an even newer, not yet existing, version might throw people off thinking a DSA has already been fixed or prevent future fixes from getting installed though. I wrote a little script that checks what apt things its installing against what the control files of the debs say. I will test it with some more fakes and then file it in the BTS. MfG Goswin
Re: exim4-config and exim4-base installed on systems with non-exim-MTA
On Thu, 4 Dec 2003 04:21:55 +1000, Anthony Towns aj@azure.humbug.org.au wrote: I'm going to ignore the -config package, since it's not really part of the problem. Is it? Okay, so you want to say: * any exim4-daemon package should only be installed when exim4-base is already installed and setup * exim4-base and shouldn't be installed when another MTA is installed * exim4-base shouldn't be installed when exim4-daemon isn't going to be installed Yes. Additionally, the three points hold for exim4-config as well. Ideally you'd have a dep loop here: exim4-daemon deps exim4-base and vice-versa. There are two options that can make that work, one is a Pre-Depends: (avoid if possible, but maybe not unreasonable), Do we need consensus on -devel to have two binary packages built from the same source declaring a pre-dependency? the other is to ensure that exim4-base (and config) is configured first, which can be done by having them not have a postinst script. That mightn't be good enough. Both -base and -config have non-trivial postinst scripts. If those solutions aren't possible, then you can have exim4-base installed without an exim4 daemon. To avoid having another MTA installed, you have to have a Conflicts: m-t-a. You thus also have to have a Provides: m-t-a. But then you have to provide /usr/sbin/sendmail, which means you need a daemon installed. So you're back to needing the circular dependencies. Right. Personally, I'd suggest not having the separate -config package; and letting sites do their own exim configurations manually, rather than by creating a replacement -config package. The way -config does the configuration is something that is questioned by a lot of people. Most conservative eximists hate the configuration being split out in several files, and having the separate -config package allows people to throw away the entire -config magic. This is something I would hate to give up. If that's really out of the question, and the -config or -base package needs a postinst atm, a Pre-Depends is probably the best option. Which package should then pre-depend on which other package? Greetings Marc, really appreciating your help -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: debsums for maintainer scripts
On Mon, 1 Dec 2003 17:12:36 -0500, christophe barbe [EMAIL PROTECTED] said: I don't see why adding a md5dsum_are_mandatory clause to the debian policy would be difficult (what would be a good reason to not add md5sum to a package?). Because it buys little security wise? Because there are solutions one can put in place today that offer better coverage than in package md5sums? manoj -- In an age when the fashion is to be in love with yourself, confessing to be in love with somebody else is an admission of unfaithfulness to one's beloved. Russell Baker Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: [RFC] adding system users: which is the best way??
On Thu, 2003-12-04 at 01:51, Andreas Metzler wrote: Steve Greenland [EMAIL PROTECTED] wrote: [...] I think the idea of a namespace for usernames used by packages is a good idea, but rather than debian-, we should take this to the LSB folk, so that we can get it done once. The problem with this is time. I need to add a system-user (for exim4) _now_. Shall I go for namespace, and if yes which one? _debian-exim, debian-dexim, DEB-exim? This might be pointing out the obvious, but anyway: If nothing else, perhaps email a freedesktop list to get a tentative/ quick discussion of the topic - put some suggestions up there if you want to pre-empt particular convention, and tell them what you chose after a few days. Pre-existing usage (if you're the first), especially as the result of discussion with the relevant people, will add something to the decision process, hopefully toward not having to make changes in the future. cheers zen -- Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/ * Homepage: http://homepages.ihug.com.au/~zenaan/ * PGP Key: http://homepages.ihug.com.au/~zenaan/zen.asc * Please respect the confidentiality of this email as sensibly warranted.
Re: Bug#222730: ITP: zope-groupuserfolder -- group management for Zope
Le Wed, Dec 03, 2003 at 08:58:19AM +0100, Andreas Tille a écrit : On Tue, 2 Dec 2003 [EMAIL PROTECTED] wrote: This package is an empty dummy package that always depends on a package built for Debian's default Python version. Why that. It should depend from Debian's Zope version or if explicite Python dependency is needed for one or the other reason it should depend from the Python version Zope is dependant from. This is not automatically the default Python version. Oups, it's a real package, but I made a copy-paste too fast. Updated description : Description: Add group management to zope GroupUserFolder is a kind of user folder that provides a special kind of user management. Some users are flagged as GROUP and then normal users will be able to belong to one or serveral groups. -- Nicolas Ledez - Virtual Net (www.virtual-net.fr) 80, avenue des Buttes de Coesmes - 35700 RENNES tel: +33 2 23 21 06 32 - fax: +33 2 99 38 16 85 pgphfEsDtRkDo.pgp Description: PGP signature
Re: OT: Smartcards and Physical Security
On Wed, 3 Dec 2003 06:54:29 -0800, Tom Ballard [EMAIL PROTECTED] said: On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote: Share the crack. In my experience kids in college and right out tend to freak out over the thought of having to spend a few dollars of disposable income, because they don't have any :-) Guess what the median age of a Debian developer is. Hey, laugh if you want, most organizations have dues, it's not unprecedented in human history :-) Volunteer organization have dues? And what services would Debian provide, pray, apart from the priviledge of working without pay? manoj -- I don't know what you mean by 'glory', Alice said. Humpty Dumpty smiled contemptuously. Of course you don't -- till I tell you. I meant 'there's a nice knock-down argument for you!' But glory doesn't mean 'a nice knock-down argument', Alice objected. When I use a word, Humpty Dumpty said, in a rather scornful tone, it means just what I choose it to mean -- neither more nor less. The question is, said Alice, whether you can make words mean so many different things. The question is, said Humpty Dumpty, which is to be master -- that's all. Lewis Carrol, Through the Looking Glass Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:26:15AM -0600, Manoj Srivastava wrote: Guess what the median age of a Debian developer is. Don't know, don't care. Volunteer organization have dues? Yes, I don't know what planet you're from, but on this planet the Rotarians, Kiwanas, Civitans, Knights of Columbus, United Way, Red Cross, Freemasons, NAACP, and Jerry's Kids all collect money from their members. You still feeling superior?
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:28:30AM -0600, Manoj Srivastava wrote: Sender: Tom Ballard [EMAIL PROTECTED] Yeah, somebody else pointed that out. It's bullshit that mutt was doing that to me. My /etc/email-addresses: # This is /etc/email-addresses. It is part of the exim package # # This file contains email addresses to use for outgoing mail. Any local # part not in here will be qualified by the system domain as normal. # # It should contain lines of the form: # #user: [EMAIL PROTECTED] #otheruser: [EMAIL PROTECTED] tom: Tom [EMAIL PROTECTED] So I thought I was covered, and my .muttrc never showed it. I fixed it. Like I said, I never thought I'd have to lie to Linux, but there you are.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Tue, Dec 02, 2003 at 05:34:05PM -0800, Don Armstrong wrote: On Tue, 02 Dec 2003, Tom wrote: I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles. Smartcards are not a magical panacea either. The problems associated No, they're not. Security is all about layers of defense. with them aren't too terribly different from those associated with keys or other forms of physical security, notably, that they can be stolen, or the output from them duplicated. Refer to the ongoing saga between DirectTV and satelite pirates for a trivially applicable example. Yes but the attacker did not steal the DD's computer. He rooted it remotely. It is true that a shitty smartcard which is only dumb storage for a private key is no better than storing your keys on an USB keyring. Good smartcards never transfer the key off the card. The smart card can be compromised itself true. Repeat: Security is about layers of defense. Multiple things have to be compromised. From my perspective, Smartcards do little to raise the bar. They merely move the bar sideways. You're wrong. They're better.
Re: exim4-config and exim4-base installed on systems with non-exim-MTA
On Wed, Dec 03, 2003 at 05:49:20PM +0100, Andreas Metzler wrote: exim4 is a metapackage that depends on the other three and is not hit by the problem. The rest is a straighforward chain. daemon -base -config. other possible dependencies would be: daemon -config -base or daemon -base `-- -config The daemon-packages provide/conflict/replaces MTA. On Wed, Dec 03, 2003 at 04:41:00PM +0100, Marc Haber wrote: This causes dselect to install exim4-base and exim4-config on a system that has some other (non-exim) MTA installed, which is a bad thing. I'm going to ignore the -config package, since it's not really part of the problem. Okay, so you want to say: * any exim4-daemon package should only be installed when exim4-base is already installed and setup * exim4-base and shouldn't be installed when another MTA is installed * exim4-base shouldn't be installed when exim4-daemon isn't going to be installed Ideally you'd have a dep loop here: exim4-daemon deps exim4-base and vice-versa. There are two options that can make that work, one is a Pre-Depends: (avoid if possible, but maybe not unreasonable), the other is to ensure that exim4-base (and config) is configured first, which can be done by having them not have a postinst script. That mightn't be good enough. If those solutions aren't possible, then you can have exim4-base installed without an exim4 daemon. To avoid having another MTA installed, you have to have a Conflicts: m-t-a. You thus also have to have a Provides: m-t-a. But then you have to provide /usr/sbin/sendmail, which means you need a daemon installed. So you're back to needing the circular dependencies. Personally, I'd suggest not having the separate -config package; and letting sites do their own exim configurations manually, rather than by creating a replacement -config package. Then you should be able to set things up so that: exim4-daemon - has a postinst which starts the daemon - Provides/Conflicts: m-t-a - Depends: exim4-base exim4-base - has no postinst - needs no configuration - provides common support files - Depends: exim4-daemon Having a check to say /etc/exim/exim.conf already exists? well, obviously you don't need any help and not asking any debconf questions is one way that should work, specifically asking do you want to configure exim manually? is another. If that's really out of the question, and the -config or -base package needs a postinst atm, a Pre-Depends is probably the best option. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgp4QJffJQsl2.pgp Description: PGP signature
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:24:07AM -0600, Manoj Srivastava wrote: Heh. Your grasp of the practicality of the situation is slipping. Not only do these guys donate a fairly expensive chunk of billable hours and expertise, they must pay to be able to volunteer? Sure, if you care about security.
Re: Backport of the integer overflow in the brk system call
On Tue, 2 Dec 2003 23:46:45 +, Geoff Richards [EMAIL PROTECTED] said: On Tue, Dec 02, 2003 at 01:28:28PM -0800, Tom wrote: I read all the words but took a completely different meaning :-) I'm from the South, we have different speech patterns... South of where? The Mason-Dixon line? manoj -- Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. Henry David Thoreau Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: The term Custom Debian Distribution (Was Re: [custom] The term flavor and encouraging work on Debian)
On Wed, 3 Dec 2003, cobaco wrote: hm, I've added a definition to the wiki: A Custom Debian Distribution (CDD) is a version of Debian that is tailored I do not like the term version. I'd prefer a subset of Debian. You get a CDD together with main but you get a helping hand to cope with the sheer mass. for a particular situation/target group out-of-the-box. Any changes necessary to Debian to support this particular situation/target group arge merged back into Debian whenever possible, improving Debian as a whole. There are no changes to Debian, because CDDs reside completely in main / testing /unstable as any other package. Kind regards Andreas.
Re: [RFC] adding system users: which is the best way??
On Sun, 2003-11-30 at 07:47, Bernhard R. Link wrote: Could anyone familar with cups explain why this is no RC-bug? From when I've seen it do it, for the same reason SWAT and webmin aren't RC bugs: They do it because the administrator said to change the config. signature.asc Description: This is a digitally signed message part
Re: Revival of the signed debs discussion
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote: But this kind of tampering _can_ be checked by apt before installing the deb simply by adding a signature verifyer into the DPkg::Pre-Install-Pkgs config option, the same mechanism apt-listchanges already uses to display only the new section of the changelog. Indeed, apt can do a lot better, and is very close to doing so. See #203741. The assumption was that the archive was compromised but the Release.gpg file changed and resigned. #203741 is about checking the Release.gpg chain of trust or is there more hidden in all the mails. Did the BTS reoder the mails, there don't seem to follow a locigal discussion. Haven't bothered to check the timestamps though. MfG Goswin
Re: Two different libpng2_1.0.12-3.woody.3_i386.deb?
On Wed, Dec 03, 2003 at 05:44:36PM +0100, Santiago Vila wrote: wget -q -O 1.deb http://ftp.debian.org/debian/pool/$file wget -q -O 2.deb http://security.debian.org/pool/updates/$file diff 1.deb 2.deb Binary files 1.deb and 2.deb differ How could this happen? Should I worry about it? $ diff -u (cd 1 find . -type f -print0 | xargs -0 md5sum) (cd 2 find . -type f -print0 | xargs -0 md5sum) --- /dev/fd/63 Wed Dec 3 18:11:59 2003 +++ /dev/fd/62 Wed Dec 3 18:11:59 2003 @@ -4,5 +4,5 @@ efcb0a3d92c575963f4cd4e4f79f425f ./usr/share/doc/libpng2/changelog.gz 54119d0a36cff7d0822489193119fc83 ./usr/share/doc/libpng2/ANNOUNCE.gz ebe766baed86109342285496d792d3ef ./usr/share/doc/libpng2/KNOWNBUG.gz -9371022fb0313ab0b2062202383c57ec ./usr/share/doc/libpng2/changelog.Debian.gz +3f9dfa57c390b6465b655e12f4b3490a ./usr/share/doc/libpng2/changelog.Debian.gz 27164cfa4772e8424149aaa801119ead ./usr/lib/libpng.so.2.1.0.12 $ diff -u (zcat 1/usr/share/doc/libpng2/changelog.Debian.gz) (zcat 2/usr/share/doc/libpng2/changelog.Debian.gz) $ It looks like that the two binary packages were built on different places but have basically the same content. Gabor
Re: INSTALL-REPORT
On Wed, Dec 03, 2003 at 09:22:14AM +0100, Werner Wobrowsky wrote: Debian Installer sarge-i386-bussinescard.iso, httP://freedesktop.or/ Cool, but... FreeBSD 5.1-RELEASE-p11 #0: Thu Nov 27 15:07:08 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEW I didn't know the sarge ISOs supported Debian/FreeBSD. :) Wrong dmesg? -- Joshua Kwan pgpIROADjx2N3.pgp Description: PGP signature
Bug#222807: ITP: distcmd -- Distribute load to multiple machines using ssh
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: distcmd Version : 0.9 Upstream Author : Anthony DeRobertis [EMAIL PROTECTED] * URL : http://ntp.derobert.net/DistCmd/ * License : GPL Description : Distribute load to multiple machines using ssh DistributedCommand allows you to run commands load-balanced over one or more machines. Notable features include performing all remote control of machines using ssh; transfering files over scp or a shared filesystem, on a per-host basis; and avoiding copying through hardlinks when possible. . Out of the box, it supports running oggenc to encode Ogg Vorbis streams. An example of how to use it with Jack the Ripper is included. NOTE: Packages are available at the above URL. That URL is not going to last forever, though I need a sponsor for this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zfVF+z+IwlXqWf4RAmR7AJ4jMHVOyJk3a5MWxTgEUXvU4r3SjQCeMqbs 71w0U2whdvZ82IBeSs+YKhE= =2HqB -END PGP SIGNATURE-
