rpm3 package still exist
rpm -qi TIVsm-API
Name: TIVsm-APIRelocations: /opt
Version : 5.3.0 Vendor: IBM
Release : 0 Build Date: Wed 08 Dec 2004
01:29:20 PM CET
Install Date: Wed 06 Jun 2007 11:42:51 AM CEST Build Host:
darkover.mainz.de.ibm.com
Group : Utilities/Archiving Source RPM:
TIVsm-5.3.0-0.src.rpm
Size: 13934052 License: Commercial
Signature : (none)
URL : http://www-3.ibm.com/software/tivoli/products/storage-mgr/
Summary : the API
Description :
IBM Tivoli Storage Manager API
rpm -q --qf '%{RPMVERSION}\n' TIVsm-API
3.0.6
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.1 (Tikanga)
On what system/distro they have built this with rpm 3.0.6 in 2008 is
mysterious for me.
Best Regards
Re: rpm3 package still exist
Prolly the same place MySQL.com builds some of theirs.
$ rpm -qpi MySQL-5.0.51a-0.src.rpm
Name: MySQLRelocations: (not relocatable)
Version : 5.0.51a Vendor: MySQL AB
Release : 0 Build Date: Mon Jan 14 06:10:22 2008
Install Date: (not installed)Build Host: build.mysql.com
Group : Applications/DatabasesSource RPM: (none)
Size: 27635629 License: GPL
Signature : (none)
Packager: MySQL Production Engineering Team <[EMAIL PROTECTED]>
URL : http://www.mysql.com/
Summary : MySQL: a very fast and reliable SQL database server
Description :
The MySQL(TM) software delivers a very fast, multi-threaded, multi-user,
and robust SQL (Structured Query Language) database server. MySQL Server
is intended for mission-critical, heavy-load production systems as well
as for embedding into mass-deployed software. MySQL is a trademark of
MySQL AB.
Copyright (C) 2000-2007 MySQL AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license.
The MySQL web site (http://www.mysql.com/) provides the latest
news and information about the MySQL software. Also please see the
documentation and the manual for more information.
$ rpm -qp --qf '%{RPMVERSION}\n' MySQL-5.0.51a-0.src.rpm
3.0.6
Jason
On Wed, Jun 25, 2008 at 10:53 AM, devzero2000 <[EMAIL PROTECTED]> wrote:
> rpm -qi TIVsm-API
>
> Name: TIVsm-APIRelocations: /opt
> Version : 5.3.0 Vendor: IBM
> Release : 0 Build Date: Wed 08 Dec 2004
> 01:29:20 PM CET
> Install Date: Wed 06 Jun 2007 11:42:51 AM CEST Build Host:
> darkover.mainz.de.ibm.com
> Group : Utilities/Archiving Source RPM:
> TIVsm-5.3.0-0.src.rpm
> Size: 13934052 License: Commercial
> Signature : (none)
> URL : http://www-3.ibm.com/software/tivoli/products/storage-mgr/
> Summary : the API
> Description :
> IBM Tivoli Storage Manager API
>
>
> rpm -q --qf '%{RPMVERSION}\n' TIVsm-API
> 3.0.6
>
> cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.1 (Tikanga)
>
> On what system/distro they have built this with rpm 3.0.6 in 2008 is
> mysterious for me.
>
> Best Regards
>
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: rpm3 package still exist, devzero2000 said (at 4:53pm on Jun...:
rpm -qi TIVsm-API
Name: TIVsm-APIRelocations: /opt
Version : 5.3.0 Vendor: IBM
Release : 0 Build Date: Wed 08 Dec 2004
01:29:20 PM CET
Install Date: Wed 06 Jun 2007 11:42:51 AM CEST Build Host:
darkover.mainz.de.ibm.com
Group : Utilities/Archiving Source RPM:
TIVsm-5.3.0-0.src.rpm
Size: 13934052 License: Commercial
Signature : (none)
URL : http://www-3.ibm.com/software/tivoli/products/storage-mgr/
Summary : the API
Description :
IBM Tivoli Storage Manager API
rpm -q --qf '%{RPMVERSION}\n' TIVsm-API
3.0.6
That was built by ibm, and the commercial UNIX vendors are notorious for
sticking with a particular version of some software to maintain backward
compatibility.
This segues nicely into a question that just came up on the NetWorker
(backup software) mailing list. EMC also packages all their RPMs for
their backup software using RPM 3.0.6, and EMC and IBM aren't the only
ones doing this.
If you try sign an RPM built with 3.0.x with a 4.X.Y version of RPM, the
RPM becomes corrupted.
Would this be something that's easy to fix -- make RPM 5.1.x capable of
signing both modern and ancient RPMs? It sure would make a lot of
sysadmins lives easier, as they wouldn't have to keep an old copy of RPM
around just to sign packages they get from vendors.
Tim
--
Tim Mooney[EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building(701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
RE: rpm3 package still exist
Tim Mooney wrote:
> In regard to: rpm3 package still exist, devzero2000 said (at 4:53pm
> on Jun...:
>
>> rpm -qi TIVsm-API
>>
>> Name: TIVsm-APIRelocations: /opt
>> Version : 5.3.0 Vendor: IBM
>> Release : 0 Build Date: Wed 08 Dec
>> 2004 01:29:20 PM CET Install Date: Wed 06 Jun 2007 11:42:51 AM CEST
>> Build Host: darkover.mainz.de.ibm.com Group :
>> Utilities/Archiving Source RPM: TIVsm-5.3.0-0.src.rpm Size
>> : 13934052 License: Commercial Signature :
>> (none) URL :
>>
>> http://www-3.ibm.com/software/tivoli/products/storage-mgr/ Summary
>> : the API Description : IBM Tivoli Storage Manager API
>>
>> rpm -q --qf '%{RPMVERSION}\n' TIVsm-API
>> 3.0.6
>
> That was built by ibm, and the commercial UNIX vendors are notorious
> for sticking with a particular version of some software to maintain
> backward compatibility.
probably sles8 or similar, at a guess.
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Wed, Jun 25, 2008 at 12:06 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: > If you try sign an RPM built with 3.0.x with a 4.X.Y version of RPM, the > RPM becomes corrupted. > > Would this be something that's easy to fix -- make RPM 5.1.x capable of > signing both modern and ancient RPMs? It sure would make a lot of > sysadmins lives easier, as they wouldn't have to keep an old copy of RPM > around just to sign packages they get from vendors. Having asked this question once or twice over the last few years I'll save Jeff the hassle of telling you that it's an insoluble problem. So short answer is if it ain't happened by now, it ain't gonna happen. Jason __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Jun 25, 2008, at 12:06 PM, Tim Mooney wrote:
In regard to: rpm3 package still exist, devzero2000 said (at 4:53pm
on Jun...:
rpm -qi TIVsm-API
Name: TIVsm-APIRelocations: /opt
Version : 5.3.0 Vendor: IBM
Release : 0 Build Date: Wed 08 Dec
2004
01:29:20 PM CET
Install Date: Wed 06 Jun 2007 11:42:51 AM CEST Build Host:
darkover.mainz.de.ibm.com
Group : Utilities/Archiving Source RPM:
TIVsm-5.3.0-0.src.rpm
Size: 13934052 License: Commercial
Signature : (none)
URL : http://www-3.ibm.com/software/tivoli/products/
storage-mgr/
Summary : the API
Description :
IBM Tivoli Storage Manager API
rpm -q --qf '%{RPMVERSION}\n' TIVsm-API
3.0.6
That was built by ibm, and the commercial UNIX vendors are
notorious for
sticking with a particular version of some software to maintain
backward
compatibility.
This segues nicely into a question that just came up on the NetWorker
(backup software) mailing list. EMC also packages all their RPMs for
their backup software using RPM 3.0.6, and EMC and IBM aren't the only
ones doing this.
If you try sign an RPM built with 3.0.x with a 4.X.Y version of
RPM, the
RPM becomes corrupted.
Yup. Sign with the same version of rpm used to build the package will
always "work" no matter what.
Would this be something that's easy to fix -- make RPM 5.1.x
capable of
signing both modern and ancient RPMs? It sure would make a lot of
sysadmins lives easier, as they wouldn't have to keep an old copy
of RPM
around just to sign packages they get from vendors.
There is no fix because the plaintext used for signing was changed
from header+payload to header-only.
So packages built by rpm-3.0.x do not include the markers necessary
to recover the canonical form of the original unchanged "immutable"
plaintext that is used by RPMv4 header-only signatures.
What is far more important (imho) is/was to preserve the use of the
header+payload
MD5 digest as an invariant *.rpm identifier. Clearly, any change to
header
or payload is impossible without voiding the header+payload digest.
Without adding the "immutable" markers to headers, then recovering
the header-only plaintext is impossible. tags were routinely replaced
in headers by rpm-3.0.x, the original information was discarded, and
so there is no concept of plaintext available with "LSB
format" (formerly
RPMv3) packages.
Could a converter be written if preserving header+payload MD5 was
not an issue? You betcha. The details necessary to do so I tried to
send to <[EMAIL PROTECTED]> this weekend past, but apparently
e-mail is becoming increasingly unreliable for communication,
I can't seem to find what I sent in the archives. Oh well ...
Here's what I wrote. The other code necessary to do the rest of
the package conversion is in build/pack.c since like forever.
=
Along these lines, you should attempt to add a SHA1 on you rregistered
header. Almost all headers (LSB and Sun java being the Luddites)
in an rpmdb carry a SHA1 to guarantee package metadata
integrity many years now. No such guarantee can be attempted unless
you also
compute and supply the necessary Header SHA1.
The code that is needed to add a header SHA1 is in build/pack.c.
Essentially (this is rpm5 code, there are minor API differences)
/* Reallocate the header into one contiguous region. */
Header h = headerReload(h, RPMTAG_HEADERIMMUTABLE);
...
size_t uhlen = 0;
void * uh = headerUnload(h, &uhlen);
DIGEST_CTX ctx = rpmDigestInit(PGPHASHALGO, 0);
const char * SHA1 = NULL;
(void) rpmDigestUpdate(ctx, uh, uhlen)
(void) rpmDigestFinal(ctx, &SHA1, NULL, 1)
headerAddEntry(h, RPMTAG_SHA1HEADER, RPM_STRING_TYPE, SHA1, 1);
Note that the ordering of tag additions is also significant. E.g.
RPMTAG_FILESTATES
should be added _AFTER_ headerReload() and the SHA1 computation I've
just described, because that's what is done during installation with
RPM.
Ditto adding RPMTAG_INSTALLTIME. FYI, the complete set of
additions is in lib/psm.c near the
case PSM_RPMDB_ADD:
code.
But I've likely digressed, sigh ...
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jason Corley said (at 12:35pm...: On Wed, Jun 25, 2008 at 12:06 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: If you try sign an RPM built with 3.0.x with a 4.X.Y version of RPM, the RPM becomes corrupted. Would this be something that's easy to fix -- make RPM 5.1.x capable of signing both modern and ancient RPMs? It sure would make a lot of sysadmins lives easier, as they wouldn't have to keep an old copy of RPM around just to sign packages they get from vendors. Having asked this question once or twice over the last few years I'll save Jeff the hassle of telling you that it's an insoluble problem. So short answer is if it ain't happened by now, it ain't gonna happen. Jason Thanks Jason. I pretty much figured that was the case, but hope springs eternal, as they say. ;-) Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
What is more, but off topic, is that, as anyone know, most commercial rpm package (when and if are distributed with rpm ), well, are a little scary in quality, at minimum rpm -q --scripts TIVsm-AP postinstall scriptlet (using /bin/sh): #!/bin/bash .. ... for f in libgpfs.so libdmapi.so libha_gs_r.so libct_cu.so do if [ -f /usr/lib/$f ] then if [[ $DEBUG_INSTALL == "1" ]]; then echo "File /usr/lib/$f found...";fi else if [[ $DEBUG_INSTALL == "1" ]]; then echo "File /usr/lib/$f not found... copy it!";fi cp $CLIENTDIR/api/bin/$f /usr/lib <-- HARGHH fi done # remove buildDate rm -f $CLIENTDIR/api/bin/.buildDate<-- HARG rm -f $CLIENTDIR/lang/.buildDate<-- HARG ### rpm -V TIVsm-API missing /opt/tivoli/tsm/client/api/bin/.buildDate missing /opt/tivoli/tsm/client/lang/.buildDate On Wed, Jun 25, 2008 at 6:41 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: > In regard to: Re: rpm3 package still exist, Jason Corley said (at > 12:35pm...: > > On Wed, Jun 25, 2008 at 12:06 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: >> >> If you try sign an RPM built with 3.0.x with a 4.X.Y version of RPM, the >>> RPM becomes corrupted. >>> >>> Would this be something that's easy to fix -- make RPM 5.1.x capable of >>> signing both modern and ancient RPMs? It sure would make a lot of >>> sysadmins lives easier, as they wouldn't have to keep an old copy of RPM >>> around just to sign packages they get from vendors. >>> >> >> Having asked this question once or twice over the last few years I'll >> save Jeff the hassle of telling you that it's an insoluble problem. >> So short answer is if it ain't happened by now, it ain't gonna happen. >> Jason >> > > Thanks Jason. I pretty much figured that was the case, but hope springs > eternal, as they say. ;-) > > Tim > -- > Tim Mooney[EMAIL PROTECTED] > Information Technology Services (701) 231-1076 (Voice) > Room 242-J6, IACC Building(701) 231-8541 (Fax) > North Dakota State University, Fargo, ND 58105-5164 > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org >
Re: rpm3 package still exist
Heh, I was ranting about something similar to Jeff on IRC yesterday with regards to a certain Compaq/HP RPM... $ rpm -ql hponcfg /usr/lib/hponcfg $ rpm -q --scripts hponcfg preinstall program: /bin/sh postinstall scriptlet (using /bin/sh): cp /usr/lib/hponcfg /sbin/ chmod 755 /sbin/hponcfg postuninstall scriptlet (using /bin/sh): if [ "$1" = "0" ]; then rm /sbin/hponcfg -f rm /usr/lib/hponcfg -f fi Jason On Wed, Jun 25, 2008 at 1:10 PM, devzero2000 <[EMAIL PROTECTED]> wrote: > What is more, but off topic, is that, as anyone know, most commercial rpm > package (when and if are distributed with rpm ), well, are a little scary in > quality, at minimum > > > rpm -q --scripts TIVsm-AP > postinstall scriptlet (using /bin/sh): > #!/bin/bash > .. > ... > for f in libgpfs.so libdmapi.so libha_gs_r.so libct_cu.so > do > if [ -f /usr/lib/$f ] > then >if [[ $DEBUG_INSTALL == "1" ]]; then echo "File /usr/lib/$f > found...";fi > else >if [[ $DEBUG_INSTALL == "1" ]]; then echo "File /usr/lib/$f not > found... copy it!";fi >cp $CLIENTDIR/api/bin/$f /usr/lib <-- HARGHH > fi > done > > # remove buildDate > rm -f $CLIENTDIR/api/bin/.buildDate<-- HARG > rm -f $CLIENTDIR/lang/.buildDate<-- HARG > ### > rpm -V TIVsm-API > missing /opt/tivoli/tsm/client/api/bin/.buildDate > missing /opt/tivoli/tsm/client/lang/.buildDate > > On Wed, Jun 25, 2008 at 6:41 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: >> >> In regard to: Re: rpm3 package still exist, Jason Corley said (at >> 12:35pm...: >> >>> On Wed, Jun 25, 2008 at 12:06 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: >>> >>>> If you try sign an RPM built with 3.0.x with a 4.X.Y version of RPM, the >>>> RPM becomes corrupted. >>>> >>>> Would this be something that's easy to fix -- make RPM 5.1.x capable of >>>> signing both modern and ancient RPMs? It sure would make a lot of >>>> sysadmins lives easier, as they wouldn't have to keep an old copy of RPM >>>> around just to sign packages they get from vendors. >>> >>> Having asked this question once or twice over the last few years I'll >>> save Jeff the hassle of telling you that it's an insoluble problem. >>> So short answer is if it ain't happened by now, it ain't gonna happen. >>> Jason >> >> Thanks Jason. I pretty much figured that was the case, but hope springs >> eternal, as they say. ;-) >> >> Tim >> -- >> Tim Mooney[EMAIL PROTECTED] >> Information Technology Services (701) 231-1076 (Voice) >> Room 242-J6, IACC Building(701) 231-8541 (Fax) >> North Dakota State University, Fargo, ND 58105-5164 >> __ >> RPM Package Managerhttp://rpm5.org >> Developer Communication Listrpm-devel@rpm5.org > > __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 12:41pm...: Could a converter be written if preserving header+payload MD5 was not an issue? You betcha. The details necessary to do so I tried to send to <[EMAIL PROTECTED]> this weekend past, but apparently e-mail is becoming increasingly unreliable for communication, I can't seem to find what I sent in the archives. Oh well ... So support for signing ancient RPMs is a no-go, but it might be possible to convert ancient RPMs to a more modern format? Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Jun 25, 2008, at 1:26 PM, Tim Mooney wrote: In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 12:41pm...: Could a converter be written if preserving header+payload MD5 was not an issue? You betcha. The details necessary to do so I tried to send to <[EMAIL PROTECTED]> this weekend past, but apparently e-mail is becoming increasingly unreliable for communication, I can't seem to find what I sent in the archives. Oh well ... So support for signing ancient RPMs is a no-go, but it might be possible to convert ancient RPMs to a more modern format? Yes. But it won't be the same package any more, any digital signatures done by the vendor will be lost, and the header+payload MD5 digest will change. The "branding" confusion when the package is altered is all that stops me from implementing the conversion. I do not want responsibility for removing vendor "branding" carried by digital signatures. Meanwhile, the incidence of "LSB format" packages is almost zero these days. The problem will eventually solve itself, adding a conversion tool changes almost nothing. But I will likely write the converter this summer no matter what. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 2:35pm on...: On Jun 25, 2008, at 1:26 PM, Tim Mooney wrote: In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 12:41pm...: Could a converter be written if preserving header+payload MD5 was not an issue? You betcha. The details necessary to do so I tried to send to <[EMAIL PROTECTED]> this weekend past, but apparently e-mail is becoming increasingly unreliable for communication, I can't seem to find what I sent in the archives. Oh well ... So support for signing ancient RPMs is a no-go, but it might be possible to convert ancient RPMs to a more modern format? Yes. But it won't be the same package any more, any digital signatures done by the vendor will be lost, and the header+payload MD5 digest will change. :-) I personally don't care about the loss of vendor signatures. Since I'm not very familiar with RPM internals, I'm not sure what all the implications are for the loss of header+payload MD5, but I'm guessing most RPM users won't care. Meanwhile, the incidence of "LSB format" packages is almost zero these days. The problem will eventually solve itself, adding a conversion tool changes almost nothing. But I will likely write the converter this summer no matter what. That's great to hear. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Jun 25, 2008, at 3:10 PM, Tim Mooney wrote: :-) I personally don't care about the loss of vendor signatures. Since I'm not very familiar with RPM internals, I'm not sure what all the implications are for the loss of header+payload MD5, but I'm guessing most RPM users won't care. Well you may not *think* you care, but this thread (like most) points out that vendor *.rpm packages cannot be resigned with modern RPM. Modern == what has been widely deployed for 6+ years. Until vendors change their packaging, the existence (or not) of a converter changes nothing whatsoever. Lusers will download vendor *.rpm packages and be surprised that they cannot resign. Furthermore, LSB's dogged persistence pursuing "LSB format" *.rpm packages is preventing the natural order of evolutionary progression. Useless software needs to be permitted to die. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Wed, Jun 25, 2008 at 8:35 PM, Jeff Johnson <[EMAIL PROTECTED]> wrote: > > On Jun 25, 2008, at 1:26 PM, Tim Mooney wrote: > > In regard to: Re: rpm3 package still exist, Jeff Johnson said (at >> 12:41pm...: >> >> Could a converter be written if preserving header+payload MD5 was >>> not an issue? You betcha. The details necessary to do so I tried to >>> send to <[EMAIL PROTECTED]> this weekend past, but apparently >>> e-mail is becoming increasingly unreliable for communication, >>> I can't seem to find what I sent in the archives. Oh well ... >>> >> >> So support for signing ancient RPMs is a no-go, but it might be possible >> to convert ancient RPMs to a more modern format? >> >> > Yes. But it won't be the same package any more, any digital signatures > done by the vendor will be lost, and the header+payload MD5 digest will > change. > > The "branding" confusion when the package is altered is all that stops > me from implementing the conversion. I do not want responsibility > for removing vendor "branding" carried by digital signatures The proprietary RPM package that i have seen, mostly from a big commercial company - useless to tell which- have no digital signature anyway. My experience only. Best Regards > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org >
Re: rpm3 package still exist
On Wed, Jun 25, 2008 at 9:25 PM, Jeff Johnson <[EMAIL PROTECTED]> wrote: > > On Jun 25, 2008, at 3:10 PM, Tim Mooney wrote: > > >> :-) I personally don't care about the loss of vendor signatures. Since >> I'm not very familiar with RPM internals, I'm not sure what all the >> implications are for the loss of header+payload MD5, but I'm guessing >> most RPM users won't care. >> >> > Well you may not *think* you care, but this thread (like most) points out > that > vendor *.rpm packages cannot be resigned with modern RPM. > > Modern == what has been widely deployed for 6+ years. > > Until vendors change their packaging, the existence (or not) > of a converter changes nothing whatsoever. Lusers will download > vendor *.rpm packages and be surprised that they cannot resign. Why lusers want to resign package they have not created in first place: if they want signed package, well, they have to ask the vendor alongside the pub key - they have already paid anymore. I am perhaps a lusers, more yes that not, but i don't do this never. Best Regards > > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org >
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:06pm on...: Why lusers want to resign package they have not created in first place: if they want signed package, well, they have to ask the vendor alongside the pub key - they have already paid anymore. So they can distribute it via their software distribution infrastructure. For example, Red Hat Satellite Server. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 3:25pm on...: Modern == what has been widely deployed for 6+ years. Jeff, I totally agree. The problem is, for better or worse, there are plenty of large commercial vendors that are still providing software that's been packaged with non-modern RPM. It's the sysadmins that are the ones who suffer. I would love to see every vendor that distributes RPMs upgrade to something that's been released in the last couple years, but based on past experience with large vendors and what I've seen so far, that's not going to happen any time soon, even with customers pushing the vendors to do so (and we are). As devzero points out, the even larger problem isn't what version the RPM is built with, it's how the software is packaged in the first place. There are a lot of really bad vendor RPMs that do pretty crazy stuff. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Jun 25, 2008, at 4:13 PM, Tim Mooney wrote: In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:06pm on...: Why lusers want to resign package they have not created in first place: if they want signed package, well, they have to ask the vendor alongside the pub key - they have already paid anymore. So they can distribute it via their software distribution infrastructure. For example, Red Hat Satellite Server. Sounds like Red Hat Satellite Server, not rpm, is missing an essential tool, if resigning "LSB format" rpms from other vendor's is the usage case. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Jun 25, 2008, at 4:19 PM, Tim Mooney wrote: In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 3:25pm on...: Modern == what has been widely deployed for 6+ years. Jeff, I totally agree. The problem is, for better or worse, there are plenty of large commercial vendors that are still providing software that's been packaged with non-modern RPM. It's the sysadmins that are the ones who suffer. I would love to see every vendor that distributes RPMs upgrade to something that's been released in the last couple years, but based on past experience with large vendors and what I've seen so far, that's not going to happen any time soon, even with customers pushing the vendors to do so (and we are). As devzero points out, the even larger problem isn't what version the RPM is built with, it's how the software is packaged in the first place. There are a lot of really bad vendor RPMs that do pretty crazy stuff. You & I certainly have no disagreements. FWIW, I'm in the late "pro-active" stages of eliminating "LSB Format" packaging, at least that is my intent. I publically offer assistance to any vendor who wishes to do better than "LSB format" distribution for their *.rpm packages. And I've also offered LSB assistance in upgrading to better than the "LSB format" repeatedly. I cannot solve the "LSB format" package problem within RPM source code without introducing additional needless complexity. Already the code for reading headers is far more tortured than useful, and most of the reason is to accomodate multiple formats, including "LSB format", transparently. A deliberate & conscious change in plaintext definition cannot be handled transparently. At this point, XAR is a better format, and is easier to achieve through engineering, than continuing to pretend that "LSB format" can (or should) be supported. None of this should surprise anyone: I've been saying the same things for 6+ years now. Only the bluntness of my tone has changed -- Enough already. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Wed, Jun 25, 2008 at 10:13 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: > In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:06pm > on...: > > Why lusers want to resign package they have not created in first place: if >> they want signed package, well, they have to ask the vendor alongside the >> pub key - they have already paid anymore. >> > > So they can distribute it via their software distribution infrastructure. > For example, Red Hat Satellite Server. I can sign the document i wrote. I can sign document, written by other, on which i have control, can update, verify the quality or, almost, i have trust. If i have to sign document, which i have paid and not have control, weel, i am crazy or silly. It is as i have to sign m$ software. Only for distribute it. So the digital signature became a joke. And i not like this. > Tim > -- > Tim Mooney[EMAIL PROTECTED] > Information Technology Services (701) 231-1076 (Voice) > Room 242-J6, IACC Building(701) 231-8541 (Fax) > North Dakota State University, Fargo, ND 58105-5164 > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org >
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:56pm on...: I can sign the document i wrote. I can sign document, written by other, on which i have control, can update, verify the quality or, almost, i have trust. If i have to sign document, which i have paid and not have control, weel, i am crazy or silly. It is as i have to sign m$ software. Only for distribute it. So the digital signature became a joke. And i not like this. I'm not saying you're wrong, but look at it this way: any time you accept a package (whether it's an RPM on Linux or a "setup.exe" on Windows) from a vendor and you install it on your system, you're placing a significant amount of trust in that vendor. If you sign a package for distribution via your software distribution mechanism (maybe it's yum, maybe it's Red Hat Satellite, maybe it's something different), you're not say that you wrote the software and that you vouch for the quality of the software: you're saying that you obtained the software from the vendor. You're vouching for its provenance, not its quality. By vouching for its provenance, you can now easily distribute this software via your software distribution method to whatever systems should have it. If "whatever systems should have it" == 10,000 systems, isn't it better to distribute it easily via your software distribution method than to do it the hard way? Either way, the software gets installed on the system. You're in no worse position by having signed it for internal distribution than you are if you hadn't. There's also no danger that some third party might see your signature on an RPM and take that as a sign that you're vouching for the quality of the software, because all of the vendors that we're talking about as part of this discussion, that are still using rpm 3.0.x, have legal restrictions on redistributing the software you've obtained from them. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 4:21pm on...: Why lusers want to resign package they have not created in first place: if they want signed package, well, they have to ask the vendor alongside the pub key - they have already paid anymore. So they can distribute it via their software distribution infrastructure. For example, Red Hat Satellite Server. Sounds like Red Hat Satellite Server, not rpm, is missing an essential tool, if resigning "LSB format" rpms from other vendor's is the usage case. I would agree that it's more pressing for Satellite to have this capability than it is for rpm5. I asked about it here because of the great segue that devzero provided, and because I knew that you would have a lot of useful info to provide on the problem, even if I didn't really expect that there would be any solution or workaround. I frankly agree with you: vendors using rpm 3.0.6 to do packaging in 2008 is just silly. Unfortunately, my experience with vendors and "vendor inertia" is that they're not going to change their ways and get the modern RPM religion any time soon. The Red Hat Satellite development team has been uniformly pleasant, helpful and responsive when people have asked questions about Satellite on the mailing list, but based on how long it's taking to get other critical features into the product, I don't see Satellite getting this support any time soon, if ever. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
On Jun 25, 2008, at 5:55 PM, Tim Mooney wrote: In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:56pm on...: I can sign the document i wrote. I can sign document, written by other, on which i have control, can update, verify the quality or, almost, i have trust. If i have to sign document, which i have paid and not have control, weel, i am crazy or silly. It is as i have to sign m$ software. Only for distribute it. So the digital signature became a joke. And i not like this. I'm not saying you're wrong, but look at it this way: any time you accept a package (whether it's an RPM on Linux or a "setup.exe" on Windows) from a vendor and you install it on your system, you're placing a significant amount of trust in that vendor. If you sign a package for distribution via your software distribution mechanism (maybe it's yum, maybe it's Red Hat Satellite, maybe it's something different), you're not say that you wrote the software and that you vouch for the quality of the software: you're saying that you obtained the software from the vendor. You're vouching for its provenance, not its quality. By vouching for its provenance, you can now easily distribute this software via your software distribution method to whatever systems should have it. If "whatever systems should have it" == 10,000 systems, isn't it better to distribute it easily via your software distribution method than to do it the hard way? Either way, the software gets installed on the system. You're in no worse position by having signed it for internal distribution than you are if you hadn't. There's also no danger that some third party might see your signature on an RPM and take that as a sign that you're vouching for the quality of the software, because all of the vendors that we're talking about as part of this discussion, that are still using rpm 3.0.x, have legal restrictions on redistributing the software you've obtained from them. The above is one of the sanest descriptions of the usage of digital signatures in software distribution I've ever read. I (being puckishly provocative ;-) would take the analysis one step further: Even the "provenance" semantic you've attached to the digital signature verification could/should be abandoned. All that's really necessary is a strong guarantee of *.rpm package integrity when distributing OSS software, whether its through RHN Satellite or any other means. Sure there are "branding" semantics that can be read into the existence of an "official" vendor signature. And you are absolutely correct that resigning (with locally known key) indicates "provenance", not anything else. But all that is needed for reliable software distribution is an "untampered" integrity guarantee. The algorithm parameters associated with DSA/RSA signing provide a very strong guarantee of "untampered", and that's all that is needed for reliable software distribution. Other issues, like "provenance", and/or "branding", can be tied to a package being distributed through other means. FWIW, I've thought seriously about teaching rpmbuild to automagically sign every package that is built. What would be ideal (imho) is a zero knowledge proof that a package is untampered since build. The algorithm I've been watching for years (it is patented afaik, but patents eventually expire) is Feige-Fiat-Shamir described in section 11.4 of the "Handbook of Applied Cryptography". A randomly generated pubkey distributed with the package likely (imho) provides a sufficiently strong guarantee for software distribution, certainly arguably stronger than no signature at all as is currently commonly practiced. If anyone has other clueful suggestions for a candidate signing algorithm that could be automatically applied to *.rpm packages, I'm more than willing to listen. But even a randomly generated RSA/DSA key-pair, with pubkey in the *.rpm package, is perhaps a stronger "untampered" guarantee. than no signature at all. Sure you can tear apart a *.rpm package maliciously, and reconstruct with malware added and Yet Another randomly generated pubkey included. Does that really matter? The *.rpm package is still "untampered" since the malware was included, which is all that is needed for the distribution pipe. (aside) Clearly, if you are distributing modified packages with included malware, you should most definitely ensure that cannot happen through other means than "trust" of a automatically signed *.rpm package. Well, duh! Note that a randomly generated pubkey certainly does not preclude signing with other algorithms like DSA/RSA, and/or with other attached "provenance"
Re: rpm3 package still exist
On Wed, Jun 25, 2008 at 11:55 PM, Tim Mooney <[EMAIL PROTECTED]> wrote:
> In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:56pm
> on...:
>
> I can sign the document i wrote. I can sign document, written by other, on
>> which i have control, can update, verify the quality or, almost, i have
>> trust. If i have to sign document, which i have paid and not have
>> control,
>> weel, i am crazy or silly. It is as i have to sign m$ software. Only for
>> distribute it.
>>
>> So the digital signature became a joke. And i not like this.
>>
>
> I'm not saying you're wrong, but look at it this way: any time you accept
> a package (whether it's an RPM on Linux or a "setup.exe" on Windows) from
> a vendor and you install it on your system, you're placing a significant
> amount of trust in that vendor.
>
> If you sign a package for distribution via your software distribution
> mechanism (maybe it's yum, maybe it's Red Hat Satellite, maybe it's
> something different), you're not say that you wrote the software and that
> you vouch for the quality of the software: you're saying that you obtained
> the software from the vendor. You're vouching for its provenance, not
> its quality
rpm5, da some years in effect. has exactly the function for the vendor to
vouch, via crypto methods and not for assertion, for provenance and
integrity for the software they do: the signature probe e.g. for example
Summary: A GNU file archiving program
Name: tar
Epoch: 2
Version: 1.17
Release: 7%{?dist}
License: GPLv2+
Group: Applications/Archiving
URL: http://www.gnu.org/software/tar/
Source0: ftp://ftp.gnu.org/pub/gnu/tar/tar-%{version}.tar.gz
Source1: ftp://ftp.gnu.org/pub/gnu/tar/tar-%{version}.tar.gz.sig
Source2: tar.1
Source3: sergey.gpg
..
#
# Here we verify the tarball (SOURCE0) using the signature (SOURCE1),
# public key (SOURCE3), and the fingerprint of the public keys
# e.g:
# gpg --list-keys --fingerprint
###
BuildRequires: signature(%{SOURCE0}:%{SOURCE1}) =
%{SOURCE3}:325F650C4C2B6AD58807327A3602B07F55D0C732
Anyway i think that this can be an example of use.
If and when they begin to use rpm5(or rpm6 ecc), perhaps on 2100, they can
use this. In the meantime. i live happy - more or less - to confine, YES
"confine", this packages in a specific yum repo - with the hope that
someday i can live finally without them.
[commercial-base]
name=commercial $releasever - $basearch - Base
baseurl=
http://vendor.example.com/yumrepo/core/$releasever/$basearch/commercial
#
# XXX no digital
# signature from the vendor
# They give me, face to face, in my hands. Hope the best
#
failovermethod=priority
enabled=1
gpgcheck=0<- ###
(aside) Satellite have oracle (and the RH rpm) in it (iirc) : do you know if
RH sign oracle RPM ? sure probabily they do but i don't know.
So depend on POV.
Thank for your reply.
