Re: Registering a media type for Debian binary packages ?
Hi Charles!
On Fri, 2014-01-03 at 10:42:09 +0900, Charles Plessy wrote:
> Le Mon, Dec 30, 2013 at 02:23:00AM +0100, Guillem Jover a écrit :
> > This sounds great in theory, but I'm worried that in practice this
> > might just make the situation worse, by making applications having
> > to support not two, but three media types for undetermined periods
> > of time?
> >
> > OTOH, this might make it clearer for developers, what's the proper
> > media type to use, so I will note down to possibly prepare a draft
> > for this in the coming weeks, if it ends up making sense to do it.
> I could not help giving it a try. What do you think of the following ?
> (see http://www.iana.org/form/media-types for background).
For local-only applications a transition to this new mime type can be
done pretty fast, as long as the local database has been updated, not
so for any application handling remote files, because they depend on
the information sent from the server, and there's really no timeframe
as when they will be able to drop support for the deprecated types. So
my question still stands though, is it really worth it? Does the IANA
recommend actively switching legacy types, or just discourages
creating them anew?
In any case here's some comments on the draft:
> Type name:
> application
>
> Subtype name:
> vnd.debian.binary-package
>
> Required parameters:
> None.
>
> Optional parameters:
> None.
>
> Encoding considerations:
> binary
>
> Security considerations:
>
> Debian binary packages can contain arbitrary commands that will be executed
Maybe state that these are “scripts containing arbitrary commands”, so
that further down it's a bit more clear that those are not required to
extract the package for inspection, for example?
> with administrator privileges during installation. It is therefore essential
> to trust the origin of the package. The recommended way is to download
> packages from APT (Advanced Packaging Tool) archives that are authenticated with
> a trusted cryptographic key (see the manual page of apt-secure for details).
> As a lesser alternative for cases where APT tools are not available, the
> package should be downloaded with secured protocols such as HTTPS. There also
> exists a mechanism for signing packages directly (called ‘debsigs’), but it is
> not deployed.
Could this be made generic as to not recommend a specific frontend
implementation, but just what's needed from it? Some systems do not
use apt, some users might want to use something else, etc. But maybe
that's not how other mime type entries are written?
> The contents of the Debian binary packages are compressed (see the ‘deb’ manual
> page for details on the format); it is therefore possible to inspect them
> without actually install the package. An estimate of the uncompressed size of
> the package may be available in its ‘control’ file, but it can only be trusted
> if the package itself is trusted.
One of the important points of the format is that it should be
extractable with “common UNIX tools”, so maybe specify this in
passing, how about something like:
The contents of the Debian binary packages are placed inside tarballs
(possibly compressed) wrapped in an ar archive (see …); it is therefore
possible to inspect them with standard UNIX tools (although the
recommended way is through ‘dpkg-deb’) without actually installing the
package.
> Since the Debian packages vehiculate programs to be installed on a computer,
> the monitoring of a user's downloads over non-secured transport protocols such
> as HTTP or FTP may reveal information pertaining to the user's privacy, or
> suggest information related to the system's security such as the precise
> version numbers of programs in use.
>
> Interoperability considerations:
>
> Arbitrary Debian binary packages can be installed on any system where the
> ‘dpkg’ package manager is used, but it is recommended to only install packages
> that have been built for a given release of Debian or a Debian derivative.
I don't think it'd be appropriate to make this Debian specific, .debs
and dpkg are used in many distributions, some not even Debian derived.
How about:
…
but it is recommended to only install packages that have been built
for a release matching the distribution installed on the system.
(maybe s/installed/running/ to avoid duplication?)
> Published specification:
> http://manpages.debian.org/deb
Unfortunately this does not seem to contain the latest version. Maybe
I could place one under http://dpkg.alioth.debian.org/, or maybe even
better, try to resuscitate the (fractal) dpkg.org domain and place it
there.
> Applications that use this media type:
>
> The Debian binary packages are manipulated by system programs such as ‘dpkg’,
> ‘apt-get’, graphical front-ends such as ’Synaptic’ but also generic archive
> decompressors such as ‘File Roller’. After downloading a package with a web
> browser or after clicking on its icon, front-ends or decompressors are usually
> started.
I'm not sure that frontends are usually started when downloading raw
.debs from the net, though.
> Fragment identifier:
> None.
>
> Restrictions on usage:
> None.
>
> Additional information:
> Deprecated alias names for this type:
> None.
That'd be the two existing ones, no?
application/x-debian-package
application/x-deb
> Magic number(s):
> Files usually start with the following string:
> !<arch>
This is not enough, this just marks any ar archive, the distinguishing
magic for a .deb is the debian-binary ar member.
> File extension(s):
> deb
>
> Macintosh file type code(s):
> None.
>
> Object Identifier(s) or OID(s):
> None.
>
> Intended usage:
> Common
Besides those comments, it looks good.
Thanks,
Guillem
Reply to: