Files-Excluded field and security implications of uscan and debian/copyright.
- To: email@example.com
- Subject: Files-Excluded field and security implications of uscan and debian/copyright.
- From: Charles Plessy <firstname.lastname@example.org>
- Date: Fri, 7 Sep 2012 08:44:36 +0900
- Message-id: <[🔎] 20120906234436.GA7066@falafel.plessy.net>
- In-reply-to: <20120825040303.GE2450@falafel.plessy.net>
- References: <20120821102121.GD14977@an3as.eu> <CAKTje6HhD392gEPadjMXkQE3VFG5J++qG1fKdRQn4sjF9bz3cw@mail.gmail.com> <20120822080938.GG8759@jones.dk> <20120825040303.GE2450@falafel.plessy.net>
Hi Andreas and everybody,
while drafting the IANA registration for the machine-readable Debian copyright
format, I had to consider and describe security implications, and realised that
in the case of the Files-Excluded field, the contents of the field are directly
executed. One can imagine scenarios where an attacker inserts in that field
some code that will cause uscan to send the developer's GPG or SSH private keys
to a remote address, etc. This can of course be corrected in uscan, but it
leads me to wonder if the copyright file should be kept as declarative as
This would mean that the fileds that are not only informative, but that are
also intended to control how a program is executed, like Files-Excluded, would
rather be placed in more specialised configuration files. For instance, one
could think a format revision 4 for debian/watch, that would use exactly the
syntax that you are implementing now, and that would embed the watch
information in a Watch field.
This would not completely solve security issues for debian/copyright, as one
can also imagine that some programs looking for files in the Files field may
also pass the values witout sanitisation to some shell commands. However, I
wonder if it would not be better to keep it as declarative as possible.
What do you think ?
Tsurumi, Kanagawa, Japan