[softwaremgmt] YMP for other distributions.
Greetings All, I recently noticed that an Ubuntu specification ThirdPartyApt[0] very similar to YMP[1]. I have since contacted the specification authors - Jerome Haltom and Scott Ritchie to enquire about the possibility of cooperating and using the same file format. Both were been interested in this possibility. Hopefully they will be subscribed to this list now. Using the same file format would make things easier for ISVs as they can write one instructions file which will do the "right thing" whichever distribution the user is using, and also do not need to learn multiple formats for doing exactly the same thing. Almost all information that can be defined in a .apt file can be defined in a .ymp (the opposite is not the case). The main difference in the proposed .apt specification is the handling of keys. It was proposed that .apt files were signed with the same key as the repository. I do not see this adds any security, and it does prevent some of the benefits we've seen with YMP by limiting its use to only the original software vendor. - Third party web based software catalogues - Reducing the length of How-Tos/Tutorials by removing complex package management instructions. - Creating YMPs for ISV packages when they are not interested in working with you to create their own (e.g. skype) Would not be possible. YMP already provides the flexibility to specify instructions for different distributions in one file. One can specify something like: <group distversion="openSUSE 10.3">...</group> <group distversion="Ubuntu 8.04">...</group> Packman[2] already make use of this to specify instructions for both openSUSE 10.3 and 10.2 in one file. There is a proof of concept implementation of a YMP client implementation for Ubuntu by one of the klik team. Video[3] Source[4]. In order to ensure that YMP can be used by Ubuntu and other distributions it may be possible to make some minor changes to the specification. At present it is possible to make minor changes without breaking backwards compatibility with 10.3. However, as more people start implementing the specification this will likely become impossible, so we should nail down any changes that are required now. Another thing to consider is whether we require a method of versioning the YMP file, incase we need to make more significant changes in the future. In terms of the data required for the mechanism to function, the only data that must be specified in a YMP file at present are: - Repository URLs - Package names The key question is whether we can specify enough information in a YMP yet to uniquely identify a Debian repository. At present one can supply the URL of the repository, and optionally: - An uri of the product within the repository to use. - The format of the repository. e.g. minimally <repository> <url>http://example.com</url> Maximally <repository recommended="true" format="yast" producturi="someaddon"> <url>http://example.com</url> Is there more information required to identify any Debian repository? Another point to consider if others implement the specification is we can no longer assume that a <group> with no distversion specified is intended for openSUSE, if other distributions implement ths specification. This means that the buildservice generated YMPs etc will have to explicitly specify the distribution they are intended for. Perhaps we could define some fallback generic distversions like "rpm" or "lsb desktop 3". There is also the question of how to distribute the public key for a debian repository. As I understand it debian repositories do not normally contain the public key as in most openSUSE repositories[5]. The .apt format proposal has the public key included in the file. This is one possibility, although in my opinion it would be better to have it available in the repositories like openSUSE, this would allow other mechanisms for adding the repository to locate the key as well. Bear in mind that one of the requirements is to keep the file format as simple as possible, the less information that is mandatory in the file the better. While we're contemplating modifications to the format I would like to add an optional "version" attribute to the software item tag. This was really only left out as an oversight and is necessary to ensure that the version of the software the user wanted is actually the one he or she gets. There is a bug report open that this is required for. Is there any other information that might be required to uniquely identify a package? Perhaps the vendor?. So - to Scott and Jerome, could you review the two specifications and point out any information you require which can not be specified with YMP. Most importantly whether repositories can be uniquely identified. It would be great to have comments,advice,and discussion from others as well. It would be best to identify problems as soon as possible. __ [0] https://wiki.ubuntu.com/ThirdPartyApt [1] http://en.opensuse.org/Standards/One_Click_Install [2] http://packman.links2linux.de [3] http://video.google.de/videoplay?docid=494315634277751745 [4] http://code.google.com/p/klikclient/source/ (ympclient subdirectory) [5] http://en.opensuse.org/Secure_Installation_Sources#The_.22repomd.22_or_.22YU... -- Benjamin Weber -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
On Tue, Mar 11, 2008 at 11:31:25AM +0000, Benji Weber wrote:
Greetings All,
I recently noticed that an Ubuntu specification ThirdPartyApt[0] very similar to YMP[1].
I have since contacted the specification authors - Jerome Haltom and Scott Ritchie to enquire about the possibility of cooperating and using the same file format. Both were been interested in this possibility. Hopefully they will be subscribed to this list now.
That is great!
[... OK ...]
There is also the question of how to distribute the public key for a debian repository. As I understand it debian repositories do not normally contain the public key as in most openSUSE repositories[5]. The .apt format proposal has the public key included in the file. This is one possibility, although in my opinion it would be better to have it available in the repositories like openSUSE, this would allow other mechanisms for adding the repository to locate the key as well. Bear in mind that one of the requirements is to keep the file format as simple as possible, the less information that is mandatory in the file the better.
<repository> ... <pubkey href="http://example.com/p.key"/> or <pubkey> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.2.2 (GNU/Linux) mQGiBD/G9AgRBACZ519LX9cdoyJA+7gmWC+mUsiyPhnmMWu4uOg0M+vb/JPtDdfc ... </pubkey> or, if not specified, it defaults to the usual suse location, for backwards compatibility. </repository> Well, reagrding signing the YMPs themselves, we may have a clash between GPG and XML, I don't know how to resolve that. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Vidner wrote:
| On Tue, Mar 11, 2008 at 11:31:25AM +0000, Benji Weber wrote:
|> Greetings All,
|>
|> I recently noticed that an Ubuntu specification ThirdPartyApt[0] very
|> similar to YMP[1].
|>
|> I have since contacted the specification authors - Jerome Haltom and
|> Scott Ritchie to enquire about the possibility of cooperating and
|> using the same file format. Both were been interested in this
|> possibility. Hopefully they will be subscribed to this list now.
|
| That is great!
Indeed :)
|> There is also the question of how to distribute the public key for a
|> debian repository. As I understand it debian repositories do not
|> normally contain the public key as in most openSUSE repositories[5].
|> The .apt format proposal has the public key included in the file. This
|> is one possibility, although in my opinion it would be better to have
|> it available in the repositories like openSUSE, this would allow other
|> mechanisms for adding the repository to locate the key as well. Bear
|> in mind that one of the requirements is to keep the file format as
|> simple as possible, the less information that is mandatory in the file
|> the better.
|
| <repository>
| ...
| <pubkey href="http://example.com/p.key"/>
| or
| <pubkey>
| -----BEGIN PGP PUBLIC KEY BLOCK-----
| Version: GnuPG v1.4.2.2 (GNU/Linux)
|
| mQGiBD/G9AgRBACZ519LX9cdoyJA+7gmWC+mUsiyPhnmMWu4uOg0M+vb/JPtDdfc
| ...
| </pubkey>
| or, if not specified, it defaults to the usual suse location, for
| backwards compatibility.
| </repository>
|
| Well, reagrding signing the YMPs themselves, we may have a clash
| between GPG and XML, I don't know how to resolve that.
Indeed. Even if the risk of collisions isn't as high when using a CDATA
section:
<repository>
~ ...
~ <pubkey><![CDATA[
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
mQGiBD/G9AgRBACZ519LX9cdoyJA+7gmWC+mUsiyPhnmMWu4uOg0M+vb/JPtDdfc
...
]]>
</pubkey>
But still. If the ASCII-armoured PGP public key token includes the
sequence "]]>" then it will break.
What would work is XML escaping the ASCII armoured block.
As that inline data is supposed to be processed by a tool that knows the
XML format, it can load the PGP public key token as a string (with DOM,
SAX, TrAX, whatever) and un-XML-escape before using it.
So even in the unlucky event where you'd have something that breaks XML
in the armoured PGP key (say, > or < or &...;):
<pubkey>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
aaa"<>bbb...
...
</pubkey>
It would look like this in the file, escaped for XML:
<pubkey>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
aaa"quot;<>bbb...
...
</pubkey>
cheers
- --
~ -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
~ /\\
On Fri, Mar 14, 2008 at 12:10:43AM +0100, Pascal Bleser wrote:
|> There is also the question of how to distribute the public key for a |> debian repository. As I understand it debian repositories do not |> normally contain the public key as in most openSUSE repositories[5]. |> The .apt format proposal has the public key included in the file. This |> is one possibility, although in my opinion it would be better to have |> it available in the repositories like openSUSE, this would allow other |> mechanisms for adding the repository to locate the key as well. Bear |> in mind that one of the requirements is to keep the file format as |> simple as possible, the less information that is mandatory in the file |> the better. | | <repository> | ... | <pubkey href="http://example.com/p.key"/> | or | <pubkey> | -----BEGIN PGP PUBLIC KEY BLOCK----- | Version: GnuPG v1.4.2.2 (GNU/Linux) | | mQGiBD/G9AgRBACZ519LX9cdoyJA+7gmWC+mUsiyPhnmMWu4uOg0M+vb/JPtDdfc | ... | </pubkey> | or, if not specified, it defaults to the usual suse location, for | backwards compatibility. | </repository> | | Well, reagrding signing the YMPs themselves, we may have a clash | between GPG and XML, I don't know how to resolve that.
Indeed. Even if the risk of collisions isn't as high when using a CDATA section: <repository> ~ ... ~ <pubkey>
mQGiBD/G9AgRBACZ519LX9cdoyJA+7gmWC+mUsiyPhnmMWu4uOg0M+vb/JPtDdfc ... ]]> </pubkey>
But still. If the ASCII-armoured PGP public key token includes the sequence "]]>" then it will break.
No, that is not a problem. The characters used are [A-Za-z0-9/+] and these don't need escaping: http://en.wikipedia.org/wiki/Base64#OpenPGP What I meant was that signing a file can be done by wrapping its contents in the GPG signature, which obviously breaks XML well-formedness. But this is actually not a big problem since we are used to detached signatures like repomd.xml has repomd.xml.asc. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
participants (3)
-
Benji Weber
-
Martin Vidner
-
Pascal Bleser