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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
