Am 25.10.2014 09:58 schrieb "Antonius Riha" <antoniusriha@gmail.com>:
>
> Hi,
> during preparation of the new log4net package, I came across section
> 3.2.5 "Signing" in the Debian cli-policy documentation. This section
> states in the 2nd paragraph:
>
> "Existing keys shipped by the source package should not be replaced
> (with mono.snk) until the next incompatible ABI change."
As I am the main author and initiator of the cli policy I can explain the motivation in this case.
This paragraph is for source packages that do not have an upstream key and the maintainer had to provide one. This is common for Windows based developers that keep the signing key private. Only in thjs case mono.snk is prefered for the next ABI breakage done by upstream. Because changing the key is an ABI breakage itself and should be avoided.
If you have an idea how it should be rephrased to be clearer please shoot and I will update the policy text.
>
> To me, this sounds like it's preferred to use mono.snk even if there is
> an upstream key available. IMO, Debian cli packages should not deviate
> from a signing key provided by upstream, because the assembly signature
> is the primary way of identifying an assembly in .NET.
>
> I'd suggest to
> * allow key changes only with ABI breaking changes (as it is now)
> * mandate key changes, if ABI changes and the best available "candidate
> key" is currently not used, with "candidate keys" being (in order of
> preference):
> 1. upstream provided key
> 2. mono.snk
>
> Is this something that makes sense? Or are there other reasons that
> outweigh the ones I presented?
>
> - antonius
>
> _______________________________________________
> pkg-cli-libs-team mailing list
> pkg-cli-libs-team@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cli-libs-team