Re: Status on Proposal for restricted packages

[john@dhh.gt.org]

Ben Collins writes:
> This isn't just for the software tho. The data related to the
> restrictions needs to be persistent, not just in the .deb file, it needs
> to stay on the system and the user should be able to reasonably
> understand the info.

Which is why the restrictions file, which contains the maintainers
explanation of the restrictions, goes in /usr/doc/<package>.

> Not true, just the most common ones that we see in almost all restrcited
> packages, which is a limited amount.

What is the point in creating an incomplete database that contains only the
common stuff that anyone involved with restricted packages already knows
about?

> This is exaclty what I was stating above, however, I and others can very
> easily tell you what ssh has that makes it restricted, but I bet very few
> people really know all of the import and export restrictions associated
> with it world-wide.

So you agree that the people maintaining restricted packages are the one
who know the subject best.

> I'de much rather say "crypto-rsa" than say "ummm, I wonder where this
> thing can and can't go?".

Then look in Raul's database.  But do so with the critical eye of someone
who knows something about the subject.  If you need help, ask on the
restrictions mailing-list.  Much more robust than a central database and a
critical piece of software.

> If a maintainer can't even recognize the type of restriction in his
> package, how would he know where the restrictions affect it?

Then what is he doing maintaining a restricted package?

Let's leave the responsibility for the package with the maintainer who is
responsible for it.  We trust the maintainer with security: why not trust
her with this?
-- 
John Hasler                This posting is in the public domain.
john@dhh.gt.org		   Do with it what you will.
Dancing Horse Hill         Make money from it if you can; I don't mind.
Elmwood, Wisconsin         Do not send email advertisements to this address.