Re: Status on Proposal for restricted packages
Hi,
>>"John" == John Hasler <john@dhh.gt.org> writes:
John> 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.
John> Which is why the restrictions file, which contains the maintainers
John> explanation of the restrictions, goes in /usr/doc/<package>.
Too much burden is being put on the maintainer, as well as
making the maintainer more liable legally. I dislike this approach,
this seems to me to be untenable.
>> Not true, just the most common ones that we see in almost all restrcited
>> packages, which is a limited amount.
John> What is the point in creating an incomplete database that
John> contains only the common stuff that anyone involved with
John> restricted packages already knows about?
What is a restricted package? What is a restricted package
today may not be one tomorrow, and unencumbvered packages may be
restricted the next week Who the hell can keep track of all the laws
in various countres?
>> 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.
John> So you agree that the people maintaining restricted packages are the one
John> who know the subject best.
Rubbish. I am a security expert. I can maintain things like
Kerberos and DCE (Frankly, not very many people have experience in
corporate security). But am I a lawyer? Hell, no I need all the help
I can get -- a database, maintained by a security list, would be
immensly helpful.
I can maintain so called restricted packages (and what s a
restricted package may change as laws are passed (note -- laws are
passed evry day). Having a central database that can be maintained by
a group with members from several countries is better positioned to
be pro-active.
>> I'de much rather say "crypto-rsa" than say "ummm, I wonder where this
>> thing can and can't go?".
John> Then look in Raul's database. But do so with the critical eye
John> of someone who knows something about the subject. If you need
John> help, ask on the restrictions mailing-list. Much more robust
John> than a central database and a critical piece of software.
The restrictions mailing list maintains the central
database. Best of both worlds. I think that the user should be in
charge of following the laws of their country, and not the
packager. The latter is untenable.
>> If a maintainer can't even recognize the type of restriction in his
>> package, how would he know where the restrictions affect it?
John> Then what is he doing maintaining a restricted package?
He is maintaining a pacage. Some government somewhere passes a
law that restricts it there. So I have to be an international lawyer
no to package things for Debian? That is not going to severly degrade
the quality of software in the project?
John> Let's leave the responsibility for the package with the maintainer who is
John> responsible for it. We trust the maintainer with security: why not trust
John> her with this?
We are software experts, and hence security of code is
something in our domain. Security is also something that is logical,
unlike laws which are not, and change without reason from country to
country. This argument does much to detract from the stand you are
attempting to take, since it indicates you have not really thought
things through.
manoj
--
A woman without a man is like a fish without a bicycle. Therefore, a
man without a woman is like a bicycle without a fish.
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: