| Author |
Message |
Adeodato Simó
*nix forums Guru Wannabe
Joined: 23 Feb 2005
Posts: 107
|
 Posted: Thu Nov 24, 2005 12:10 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
* Matthew Palmer [Thu, 24 Nov 2005 22:54:58 +1100]:
| Quote: | Sorry, that was a massive typo on my part. I thought "buildd output", and
wrote "buildd logs" when I meant "buildd .changes files". My question, as
amended, though, still holds -- are the .changes associated with the upload
of autobuilt packages supposed to go to d-d-c, and if so, are they there and
I'm just not seeing them in the list archive?
|
They go to the respective debian-devel-$ARCH-changes list, none of
which is archived AIUI.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
You cannot achieve the impossible without attempting the absurd.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
Henrique de Moraes Holsch
*nix forums Guru
Joined: 21 Feb 2005
Posts: 541
|
| Posted: Thu Nov 24, 2005 12:50 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Thu, 24 Nov 2005, Anthony Towns wrote:
| Quote: | On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote:
On Thu, 24 Nov 2005, Anthony Towns wrote:
Personally, I think it's cryptographic snake oil, at least in so far
A signed deb has a seal of procedence and allows one to track the path it
made through the system, and who changed it.
That's what the .changes file is for.
|
Well, assuming .changes is not snake-oil, then why should in-deb sigs be
called snake-oil? After all, according to you they essentially do the same
job.
Still, .changes file do not carry all the information in-deb sigs do
(although they could, if we sign the .changes files more than once -- but
changes are DAK will croak on that too). They're not stored along with the
..debs anywhere (we could change that too, I suppose... but I doubt one extra
file per source in the archive will be welcome). They are *far* from being
as simple to handle as in-deb signatures.
Not to mention that doing the inverse path (from .deb to .changes) is far
more complicated than using in-deb sigs, and is only possible in fact if you
either always respect some sort of naming convention to go from source
package to .changes (and this *IS* a kludge), or if you read all .change
files hunting for the file you want in the MD5s.
| Quote: | Uh, packages not uploaded to the official Debian archive can do whatever
they want.
|
Sure. But I for one won't be building all debs twice, and many others won't
either. And proper support for in-deb signatures means added functionality
in a lot of other utilities that won't happen if Debian doesn't use in-deb
signatures, etc.
So, it makes a damn big difference if the Debian archive accepts signed debs
or not.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Henrique de Moraes Holsch
*nix forums Guru
Joined: 21 Feb 2005
Posts: 541
|
| Posted: Thu Nov 24, 2005 1:20 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Thu, 24 Nov 2005, Anthony Towns wrote:
| Quote: | You can already use release signatures for this. Further, changing the
deb after upload would make it much more difficult to check the deb was
what was uploaded -- you can no longer just use md5sum, you've instead
got to use special tools.
|
While the point about "you can no longer just use md5sum" is useless (you
need gpg, other "special" tools won't make it any more difficult, especially
since they are gzip and ar), the point about not changing the .deb after
upload is a very good one. In fact, the only good point against in-deb
signatures I've seen so far.
| Quote: | Sure; but why do that inside the .deb? You can verify a detached signature
just as easily as an inline one (gpgv sig file // gpgv file), and you
|
IF this means we can switch the effort to a detached signature that is more
powerful than a .changes file (or we are allowed to have multiple signatures
in a .changes file), and also that the .changes file will be stored in the
archives along with the .debs, and that .debs with wrong/incomplete/missing
Source: fields will be rejected (such as all automated bin-NMUed .debs made
until about a week ago, or any made by a maintainer right now), and that the
path to go from the Source:-field to the .origin/.changes file name is set
in stone... then yes, detached signatures would do it.
| Quote: | My objection is that it's *useless* for *Debian*. Debian has too many
sources for packages for key management to be plausible, and keeps
|
This applies to .changes files too, with the aggravating addition that those
are a b***h to find right now.
| Quote: | authenticated both via Packages.gz files and .changes files, which
already exist and are usable.
|
ONLY if we change the way .changes files are stored. It would be best to
have them stored in the archive itself along the .debs, really, if we're
going to use them for anything other than initial acceptance through DAK.
However, integrating this on the tools will be far more difficult than an
in-deb signature (still doable, of course), where dpkg would simply refuse
per user-set policy any non-signed deb or any deb without a specific
signature...
| Quote: | This is what .changes files are for, and it's useful both for recovering
from compromises and in a "cvs blame" sort of sense. Note that they also
give more information than a simple signature on the .deb.
|
Only if we can sign it multiple times, which is one of the capabilities of
the "simple signature on the .deb" we are talking about.
| Quote: | Hrm, I see queue/done (which contains .changes files going back to the
dark ages) isn't even being mirrored to merkel properly at the moment.
That's not so constructive.
|
Agreed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Simon Richter
*nix forums addict
Joined: 14 Mar 2005
Posts: 62
|
| Posted: Thu Nov 24, 2005 3:30 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Hi,
Henrique de Moraes Holschuh wrote:
| Quote: | Well, assuming .changes is not snake-oil, then why should in-deb sigs be
called snake-oil? After all, according to you they essentially do the same
job.
|
Not exactly. .changes files say that the archive should be changed. If
the archive were to accept any signed .deb just because a developer
signed it, that would be bad(tm).
Simon |
|
| Back to top |
|
|
Florian Weimer
*nix forums Guru
Joined: 19 Feb 2005
Posts: 418
|
| Posted: Thu Nov 24, 2005 5:30 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
* Anthony Towns:
| Quote: | Personally, I think it's cryptographic snake oil, at least in so far
as it relates to Debian. I remain interested in seeing any realistic
demonstration of how a Debian user could reasonably rely on them for
any practical assurance.
|
The assurance doesn't come from the signature, but from the procedures
that create it and leave a cryptographically secured audit trail on
the binary package. The approach chosen by dpkg-sig makes it possible
to add further signatures while the package is propagated through
Debian's infrastructure (unless there are some instances of
compare-by-hash hard-wired into it, but there aren't AFAIK).
Of course, with current state of technology, there can't be a digital
signature that directly says that "installation of this package will
not cause any harm". But this doesn't mean that we should give up
completely.
So, just to be clear, revision 1.58 (which has been committed in the
meantime) is equivalent (if not identical) to the production version,
and adding metadata in the way dpkg-sig does is no longer possible?
| Quote: | Since there is no way for Debian Developers to review the way Debian
packages are created (and it's totally out of question for end users),
buildd.debian.org gives full logs, to developers or users.
|
But what do you do if there is a discrepancy between the hash in those
logs and the package which is actually in the archive? I don't know
how common this would be; the hashes on buildd.debian.org are not in a
readily extractable format, it seems.
Oh, and I looked again at the buildd stats after some time. Good to
see that m68k is not lagging behind as dramatically as it used to.
Debian is not doomed after all. 8-)
| Quote: | something that provides DD-to-user package signatures at least in some
cases is very desirable indeed.
debian-devel-changes provides this.
|
AFAIK, binary NMus aren't announced on debian-devel-changes.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Thu Nov 24, 2005 6:20 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Anthony Towns <aj@azure.humbug.org.au> writes:
| Quote: | On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote:
2) A signature from dinstall saying "this package was installed in the
Debian archive" would provide a means of automatic "assurance" of the source
of a binary package, when I'm putting together custom CDs or package repos.
You can already use release signatures for this. Further, changing the
|
Only if you have a release signature corresponding to every deb and
the Packages files where that deb was in. If you collect debs over any
amount of time that would become a huge archive.
| Quote: | deb after upload would make it much more difficult to check the deb was
what was uploaded -- you can no longer just use md5sum, you've instead
got to use special tools.
|
So? Is that so bad?
Also so far nothing is changing debs after upload. The deb signatures
so far are all done prior to uploading and even changes file
generation. Only a dinstall signature would change that, making the
changes file less easy to verify while keeping everything else the
same.
| Quote: | 3) I can verify the provenance of a particular package in my own custom
repos at any time (did that come from Debian? Did someone build it
internally? What's going on?) I can kinda-sorta do that if I manually sign
each binary package I download & verify against the Packages->Release chain
with a special "came from Debian" key, and I can verify the source of the
source (heh) package via the dsc signature, but having a complete "chain of
custody" on a binary package seems like a "nice" thing to have.
Sure; but why do that inside the .deb? You can verify a detached signature
just as easily as an inline one (gpgv sig file // gpgv file), and you
can verify a signature of a hash just as easily as a signature of a file.
If you're worried you might lose the detached, signed information, either
keep it with the data it's authenticating (pool/main/f/foo/foo.origin,
eg), or keep good backups, or both.
|
I've requested that the changes files be kept along with the debs in
pool several times. It aparently isn't going to happen. Also a
detached signature needs more space since it uses another inode and a
full block on the filesystem instead of just the few bytes inside the
deb.
And yes, I am worried about loosing the detached signatures. Why risk
it if we have a perfect mechanism without it?
| Quote: | At the very least, though, I can't find a hole which makes binary package
signatures, done properly, any less secure than per-archive signing.
That's easy: you trust the Packages file to be correct when using apt,
and it's not verified at all by per-package signatures.
|
In what way trust and how does that change anything?
At best you can prevent a newer version of a package to appear in the
Packages file by compromising it. You can't subvert a package itself.
But you can already ship yesterdays Release.gpg, Release and Packages
file to a user and thereby prevent any updates.
On the other hand, without package signatures ftp-master adds a
vulnerability. You can hack into it, replace debs, recreate the
Packages, Release and Release.gpg file and thereby infect users. With
signed debs that could still be detected by every user in apt-get.
It is not that I don't trust ftp-master but that I don't even have to
trust it.
| Quote: | Is your
objection to binary-package signing that it is "no better" than archive
signing, or that it is actively *worse* than per-archive signing (again, if
both are done "properly", whatever we may define that to mean).
My objection is that it's *useless* for *Debian*. Debian has too many
sources for packages for key management to be plausible, and keeps
packages unchanged over too long a period for the keys to be guaranteed
secure for the lifetime of a package. Additionally, packages can be
authenticated both via Packages.gz files and .changes files, which
already exist and are usable.
|
Changes files are not publicly accessible on demand so they are not
practical for any authentication. And even if you have a changes file
at hand by chance its signature has exactly the same security as
debsig has. It is as secure as the DDs key. The major difference is
the accessibility.
And Packages.gz has a 24h lifetime at worst. It is only a temporary
means to validate a deb.
So both methods are, to put it in your words, *useless* for *users*.
Please have a bit of an open mind and don't just think about what the
archive needs.
| Quote: | One scenario, which initially seems compelling, but which I've since
rejected, is that of "offline signing" of binary packages -- the idea that
the archive can be authenticated via signatures applied to packages before
they hit the archive.
This is what .changes files are for, and it's useful both for recovering
from compromises and in a "cvs blame" sort of sense. Note that they also
give more information than a simple signature on the .deb.
Hrm, I see queue/done (which contains .changes files going back to the
dark ages) isn't even being mirrored to merkel properly at the moment.
That's not so constructive.
|
That isn't publicly available. If you want changes file to be anywere
as usefull as debsig signatures then put them into pool along with
each deb. Unless users can download changes files when needed they
just can't count.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Thu Nov 24, 2005 6:40 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Simon Richter <Simon.Richter@hogyros.de> writes:
| Quote: | Hi,
Henrique de Moraes Holschuh wrote:
Well, assuming .changes is not snake-oil, then why should in-deb sigs be
called snake-oil? After all, according to you they essentially do the same
job.
Not exactly. .changes files say that the archive should be changed. If
the archive were to accept any signed .deb just because a developer
signed it, that would be bad(tm).
Simon
|
The only differences between accepting signed debs and signed changes
files are that changes file have some additional infos (like who gets
the ACK mails) and what set of debs go together.
Both features are still needed with signed debs and nobody has any
intention of changing them. The only request so far is to not reject
debs that are also signed themself.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Frank Küster
*nix forums Guru
Joined: 20 Feb 2005
Posts: 432
|
| Posted: Thu Nov 24, 2005 6:40 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
| Quote: | Anthony Towns <aj@azure.humbug.org.au> writes:
deb after upload would make it much more difficult to check the deb was
what was uploaded -- you can no longer just use md5sum, you've instead
got to use special tools.
So? Is that so bad?
Also so far nothing is changing debs after upload. The deb signatures
so far are all done prior to uploading and even changes file
generation. Only a dinstall signature would change that, making the
changes file less easy to verify while keeping everything else the
same.
|
If such a signature mechanism is implemented, dinstall could also append
a copy of the filelist, with updated md5sums. I'm not familiar with the
ar format, but can one restore the old md5sum when you unpack the deb,
remove the additional signature, and re-ar it?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Thu Nov 24, 2005 6:40 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Anthony Towns <aj@azure.humbug.org.au> writes:
| Quote: | On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote:
Then there's the opposite argument about "why not do that inside the .deb?".
Simple answers: unnecessary bloat, unwarranted feeling of security
leading to bad decisions.
|
Where do you have an unwarranted feeling of security? You keep hinting
at debsig being insecure but nothing you have said makes it any
different (security wise) from changes files.
| Quote: | Whenever anyone asks "how do you manage the keys", the answer is usually
"automatically sign by dinstall" which means the deb is modified after it
leaves the builders system (invalidating existing authentication methods)
and usually means changing the deb after its entered the archive (for
signatures identifying packages released as part of sarge / etch, or in
the case where an old key expires).
|
That is just plain wrong. The only existing debsig signatures are all
done by the builder and/or DD prior to creating the changes file. And
that is all what the initial post in this thread was about.
Having dinstall _also_ sign debs is an option that can be implemented
or not. And it would only invalidate one authentication method: using
a plain md5sum and the changes files. The Packages files md5sum would
naturaly be the md5sum after signing and still work.
Let me repeat this for you: An automatic dinstall signature is just an
option.
....
| Quote: | That's a good point. However, what damage can be done with a bodgy Packages
file, if only well-signed .debs are actually accepted for installation on
the system?
Add a "Depends: some-random-package" that you know has a security hole
to dpkg's entry in the Packages and it'll be automatically installed by
apt. Add a "Conflicts: dpkg" to some package's entry and it'll never be
installed by apt or aptitude. You can possibly be trickier by pointing
apt at a completely different file too, so that the user thinks they're
installing foo, but end up with bar instead only noticing if they see
dpkg say "Unpacking bar (from .../foo_*.deb)". IIRC, it's tricky to make
that actually work.
|
All you do there is install a trusted package or sabotage installing a
package. An attacker still can't change any package. And all of that
you can do with or without package signatures. If the original package
is buggy too bad. That is what we have security.debian.org for.
Signed debs are not ment to protect the Packages file, we have the
Release file for that. Signed debs are ment to protect the deb itself.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Goswin von Brederlow
*nix forums Guru
Joined: 20 Feb 2005
Posts: 658
|
| Posted: Thu Nov 24, 2005 6:50 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Anthony Towns <aj@azure.humbug.org.au> writes:
| Quote: | On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
Use 1: I have this deb in my apt-move mirror and I want to know if it
was compromised on yesterdays breakin
Boot a clean system with debian keyring and check all deb
signatures.
Find some don't pass because they were signed with keys that have been
removed from the keyring.
|
Those I remove and refetch from a clean source again. False negatives
are no big deal. 99% of the debs will verify leaving only a
managable amount of wokr behind.
| Quote: | Use 2: I have this Ubuntu CD and want to know which debs are from
debian and which got recompiled
Look for all debs that have a deb signature of the debian archive
(to be added to dinstall at some point).
Never to be added, because it would change the .deb from that which was
originally uploaded, for no benefit.
|
Fair enough.
| Quote: | Use 3: The debian servers were compromised and the security team takes
too long to check the archive for my taste
Being a normal user I obviously have no mail archive of all the
old changes files laying around so that road is closed. But everyone
has a Debian stable CD with keyring. See Use 1.
And see why it doesn't work. Not to mention keys added since stable
released, and packages uploaded by those maintainers.
More than just keys removed from the keyring, there's the issue of keys
being compromised -- it's not even unknown for developers to post secret
keys to mailing lists -- the issue that a package that's once been in the
|
Compromised keys are compromised keys. No matter what you use for
authentification they don't change. One has to look for revocation
certificates and remove bad keys from the keyring prio to checking
signatures.
| Quote: | archive may well by now have known security holes (which is why we have
|
As for known security holes in packages. They are known. The signature
of a deb only tells me that no new holes were added. And yes, that is
what we have security.debian.org for.
| Quote: | security.debian.org after all), and that this is entirely moot anyway
since the vast majority of packages can't be verified by dpkg-sig.
|
Ah, I see the light.
Signatures are useless because packages have no signatures.
Lightbulbs do not work because without lightbulbs it is dark.
You can't breath air because there is no oxygen in a vacuum.
| Quote: | buildd.debian.org gives full logs, to developers or users.
While the log contains the md5sum of each build deb it does not
contain any signature against tampering.
No, that's what the signed .changes file is for.
|
Which aren't readily available to the public.
| Quote: | Tampered debs can be uploaded by sending a fake mail to the admin and
filtering out his responce. A deb signature of the buildd and a
subsequent dak check would prevent this.
So would having the buildd sign the mails to the buildd admin, which would
have the benefit of not giving a couple of dozen completely untrustworthy
keys special access to the archive. (AIUI, signed mails to the admin are
on the TODO list; at present buildds don't have keys of their own at all)
|
Nothing in signed debs gives any keys additional access to the
archive. Checking for a buildd signature would only restrict the
access further from what we have already, not weaken it.
| Quote: | something that provides DD-to-user package signatures at least in some
cases is very desirable indeed.
debian-devel-changes provides this.
That covers only the sourcefull uploads and the arch specific -changes
lists are not archived and therefore useless for non constant
monitoring.
Far easier to fix that, than retrofit 150G of debs to a flawed and
redundant scheme like this.
Cheers,
aj
|
Where is there any flaw? You still haven't shown any that changes
files don't also have.
As to redundant. Yes they are redundant to changes files, IF ONLY one
could get a changes file when needed and have multiple signatures in it.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Marc 'HE' Brockschmidt
*nix forums beginner
Joined: 07 Apr 2005
Posts: 40
|
| Posted: Thu Nov 24, 2005 7:30 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Frank Küster <frank@debian.org> writes:
| Quote: | If such a signature mechanism is implemented, dinstall could also append
a copy of the filelist, with updated md5sums. I'm not familiar with the
ar format, but can one restore the old md5sum when you unpack the deb,
remove the additional signature, and re-ar it?
|
You can simply strip off the parts that change the md5sum, without the
unpack/pack cycle. The problem is to know which parts need to be removed.
Marc
--
BOFH #335:
the AA battery in the wallclock sends magnetic interference |
|
| Back to top |
|
|
Adeodato Simó
*nix forums addict
Joined: 29 Jun 2005
Posts: 74
|
| Posted: Fri Nov 25, 2005 12:30 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
* Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]:
Hi,
| Quote: | AFAIK, binary NMus aren't announced on debian-devel-changes.
|
Binary-only uploads are announced in the appropriate
debian-devel-$ARCH-changes list.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
As scarce as truth is, the supply has always been in excess of the demand.
-- Josh Billings
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Fri Nov 25, 2005 2:00 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
| Quote: | Uh, packages not uploaded to the official Debian archive can do whatever
they want.
It would, however, be convenient to be able to upload a package to
Debian and to be able to use the same package for different things.
|
As far as dpkg-sign's concerned, can't you already do that by building
the package, uploading it to debian, then running dpkg-sign? At worst
you'd have to run dpkg-genchanges again before uploading to your other
suite, afaics.
| Quote: | Allowing things like these is what makes it possible for some people
to work for Debian during their paid time.
|
Cheers,
aj |
|
| Back to top |
|
|
Henrique de Moraes Holsch
*nix forums Guru
Joined: 21 Feb 2005
Posts: 541
|
| Posted: Fri Nov 25, 2005 2:30 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Thu, 24 Nov 2005, Anthony Towns wrote:
| Quote: | On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote:
Uh, packages not uploaded to the official Debian archive can do whatever
they want.
It would, however, be convenient to be able to upload a package to
Debian and to be able to use the same package for different things.
As far as dpkg-sign's concerned, can't you already do that by building
the package, uploading it to debian, then running dpkg-sign? At worst
you'd have to run dpkg-genchanges again before uploading to your other
suite, afaics.
|
You're correct.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Fri Nov 25, 2005 4:00 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Thu, Nov 24, 2005 at 06:44:37PM +1100, Matthew Palmer wrote:
| Quote: | On Thu, Nov 24, 2005 at 03:48:15PM +1000, Anthony Towns wrote:
On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote:
I think the final judgment in this issue is going to come down to personal
taste and needs more than anything else.
That's fine for personal repositories, it's not sufficient for Debian's
archive.
Well, I think that personal taste is sufficient for Debian's archive, and it
seems obvious that Those In The Know have decided that they prefer one taste
over another. <grin
|
*sigh* Do you really think that comment was helpful?
| Quote: | Add a "Depends: some-random-package" that you know has a security hole
to dpkg's entry in the Packages and it'll be automatically installed by
apt.
You're a lot more devious than I am, AJ, as I'd never considered these
possibilities.
|
I've had this same conversation a dozen times before...
| Quote: | No, there isn't anything, apparently the mirroring to merkel got disabled
due to the inode usage / rsync time. There's some 700k odd changes
files.
Ouch. rsync must be *loving* those.
|
Well, it's loving them being excluded, yeah...
Developers who'd like to play with making a workable format for .changes
files can play around with changes files separated by month up 'til
2005/04 by poking around in /org/ftp.debian.org/queue/done on merkel;
changes up 'til August are also available unseparated, but you're better
off just ignoring those for experimenting.
Cheers,
aj |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
Distributions
»
Debian
»
devel
