Stefano Zacchiroli | 1 Nov 2011 16:12
Picon
Favicon

Re: trademark licenses and DFSG

On Sun, Oct 09, 2011 at 08:02:01PM +0200, Stefano Zacchiroli wrote:
>   as recent events have shown, we need to discuss our general stance on
> trademarks and the impact that trademark licenses (should) have on the
> content of the Debian archive.

Let's resurrect this.

We seem to have one big missing ingredient to proceed in this
discussion. Namely, we lack "competent legal advice" --- as Steve put it
--- on which kind of restrictions trademark law will impose on us. There
is a doubt about what "default" trademark restrictions will allow us to
modify in a software that contains some trademark encumbered material.

I'll seek such an advice via SPI lawyers and let you know.

In the meantime, there is an independent part of the discussion that can
proceed in its own right (and that, TBH, I'm a bit surprised has stopped
so quickly).  Let's proactively assume the following "reasonable"
outcome of the legal advice I'm going to seek:

- we are allowed (by trademark law) to ship unmodified copies of
  trademark encumbered material
- we are required to change trademark encumbered material which is
  user-visible [1] in case we change something in the software that
  might affect its functionalities (potentially any functional change)

According to my reading of the thread thus far, it seems to me we can
have consensus in considering the above fine wrt DFSG, thanks to the
*spirit* of DFSG ยง4, even though its *letter* was written to only take
into account "differnt name or version number".
(Continue reading)

Mike O'Connor | 2 Nov 2011 16:37
Picon
Favicon

Re: trademark licenses and DFSG

On Tue, 1 Nov 2011 11:12:15 -0400, Stefano Zacchiroli <leader <at> debian.org> wrote:
Non-text part: multipart/signed
> Let's proactively assume the following "reasonable"
> outcome of the legal advice I'm going to seek:
> 
> - we are allowed (by trademark law) to ship unmodified copies of
>   trademark encumbered material

I don't think it is necessarily this simple, as one work might be
considered infringing on a trademark of some other entity.  I had to
rename an ion3 extension in order comply with the ion3 trademark
license, even though the software was being shipped was not a creation
of the ion3 trademark/copyright owner and was otherwise unmodified.

> - we are required to change trademark encumbered material which is
>   user-visible [1] in case we change something in the software that
>   might affect its functionalities (potentially any functional change)
> 

I also do not believe it would be this simple.  We ship functionally
modified versions of the Linux kernel, but I do not believe there is any
reasonable expectation that we re-brand the Linux kernel.  We are also
shipping modified versions of GNOME components, but the owners of this
mark have made it clear that they don't expect us to stop using their
mark.  I don't think that changing these is beneficial to anyone.  I
doubt that there is anyone willing to do this work, and if there was, I
think it would be a waste of valuable resources.

Trademarks are nowhere near as simple to deal with as copyrights.  Its
easy for us to determine with relative accuracy, who the copyright
(Continue reading)

Jakub Wilk | 3 Nov 2011 17:38
Picon
Favicon

Re: Security guidelines for Debian people

* Lars Wirzenius <liw <at> liw.fi>, 2011-10-30, 17:33:
>>Personally, I think some guidelines for DD's about securing their 
>>personal machines where their private keys are located would be a good 
>>idea. It would be a lot better than just having a vague and ineffable 
>>thing called "trust".
>
>I agree. I offer the following as a first approximation, targeted 
>specifically for key management.
>
>* These are meant to provide an idea of the minimal acceptable standard.
>* Store your master PGP keys on at least two USB thumb drives.

This seems to suggest that having multiple copies of the PGP key somehow 
improves security. However, at least for some attack scenarios, it's 
quite the opposite.

More copies means more things that could be stolen. And backups are 
often stored in distant locations, so it might be easier to swipe the 
copy without you noticing.

--

-- 
Jakub Wilk

Picon
Favicon

Re: Security guidelines for Debian people

On Thu, 03 Nov 2011, Jakub Wilk wrote:
> * Lars Wirzenius <liw <at> liw.fi>, 2011-10-30, 17:33:
> >>Personally, I think some guidelines for DD's about securing
> >>their personal machines where their private keys are located
> >>would be a good idea. It would be a lot better than just having
> >>a vague and ineffable thing called "trust".
> >
> >I agree. I offer the following as a first approximation, targeted
> >specifically for key management.
> >
> >* These are meant to provide an idea of the minimal acceptable standard.
> >* Store your master PGP keys on at least two USB thumb drives.
> 
> This seems to suggest that having multiple copies of the PGP key

Multiple *offline* copies, in an encrypted container.

> somehow improves security. However, at least for some attack
> scenarios, it's quite the opposite.

The problem is that those offline copies are the only full copies that
are supposed to exist, as you're not supposed to have any online copies
of the master key, just copies of the subkeys.

You can get away with just one offline copy, but it better not be on
normal media or you could lose it entirely.  You can simply store both
offline copies at the same site if you want to manage key exposure risk,
as that increases the risk of key exposure by a very small margin (two
encrypted containers, might or might not make it easier to break
depending on what exactly you did), and decreases the risk of the key
(Continue reading)

Kumar Appaiah | 4 Nov 2011 03:20
Picon
Favicon
Gravatar

Re: Security guidelines for Debian people

On Thu, Nov 03, 2011 at 03:44:36PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 03 Nov 2011, Jakub Wilk wrote:
> > This seems to suggest that having multiple copies of the PGP key
> 
> Multiple *offline* copies, in an encrypted container.
> 
> > somehow improves security. However, at least for some attack
> > scenarios, it's quite the opposite.
> 
> The problem is that those offline copies are the only full copies that
> are supposed to exist, as you're not supposed to have any online copies
> of the master key, just copies of the subkeys.
> 
> You can get away with just one offline copy, but it better not be on
> normal media or you could lose it entirely.  You can simply store both
> offline copies at the same site if you want to manage key exposure risk,
> as that increases the risk of key exposure by a very small margin (two
> encrypted containers, might or might not make it easier to break
> depending on what exactly you did), and decreases the risk of the key
> becoming irretrievable due to device malfunction a great deal.

Just my opinion:

Personally, I believe there are several things which are important to
one's identity and cannot have many copies (or even one copy). For
instance, this could be a passport, or some bank access card or the
like. I would accord the same safety standards to the backup as I
would to the other documents I mentioned. That's the best I can do,
since losing (or compromise) any of the other documents is likely to
land me in a soup bigger than the loss of the key.
(Continue reading)

Thijs Kinkhorst | 5 Nov 2011 08:56
Picon
Favicon

Re: Security guidelines for Debian people

On Thu, November 3, 2011 18:44, Henrique de Moraes Holschuh wrote:
> On Thu, 03 Nov 2011, Jakub Wilk wrote:
>> * Lars Wirzenius <liw <at> liw.fi>, 2011-10-30, 17:33:
>> >>Personally, I think some guidelines for DD's about securing
>> >>their personal machines where their private keys are located
>> >>would be a good idea. It would be a lot better than just having
>> >>a vague and ineffable thing called "trust".
>> >
>> >I agree. I offer the following as a first approximation, targeted
>> >specifically for key management.
>> >
>> >* These are meant to provide an idea of the minimal acceptable
>> standard.
>> >* Store your master PGP keys on at least two USB thumb drives.
>>
>> This seems to suggest that having multiple copies of the PGP key
>
> Multiple *offline* copies, in an encrypted container.

This thread reminds me of a Dutch management book entitled "Managing
Professionals? Don't do it!"[1].

We shouldn't prescribe how many copies of a key one should keep where in
which crypto containers, or whether you should use an USB thumb drive,
smart card or a floppy to do it.

DD's are technically competent people and are perfectly able to decide
what adequate protection for their private key material should look like.
They don't need the guidelines for that, in fact, they can do without the
associated signal that there's a need that they be micromanaged about
(Continue reading)

Andreas Schuldei | 5 Nov 2011 11:51

Re: Security guidelines for Debian people

* Thijs Kinkhorst (thijs <at> debian.org) [111105 08:57]:
> On Thu, November 3, 2011 18:44, Henrique de Moraes Holschuh wrote:
> > On Thu, 03 Nov 2011, Jakub Wilk wrote:
> >> * Lars Wirzenius <liw <at> liw.fi>, 2011-10-30, 17:33:
> >> >>Personally, I think some guidelines for DD's about securing
> >> >>their personal machines where their private keys are located
> >> >>would be a good idea. It would be a lot better than just having
> >> >>a vague and ineffable thing called "trust".
> >> >
> >> >I agree. I offer the following as a first approximation, targeted
> >> >specifically for key management.
> >> >
> >> >* These are meant to provide an idea of the minimal acceptable
> >> standard.
> >> >* Store your master PGP keys on at least two USB thumb drives.
> >>
> >> This seems to suggest that having multiple copies of the PGP key
> >
> > Multiple *offline* copies, in an encrypted container.
> 
> This thread reminds me of a Dutch management book entitled "Managing
> Professionals? Don't do it!"[1].
> 
> We shouldn't prescribe how many copies of a key one should keep where in
> which crypto containers, or whether you should use an USB thumb drive,
> smart card or a floppy to do it.

i agree, rules like that become silly, quickly. but if someone
explains good "best practice" to me and motivates why it is
better then the alternatives, and how to integrate it into your
(Continue reading)

Picon
Favicon

Re: Security guidelines for Debian people

On Sat, 05 Nov 2011, Thijs Kinkhorst wrote:
> This thread reminds me of a Dutch management book entitled "Managing
> Professionals? Don't do it!"[1].

Being an engineer, I can tell you that publishing guidelines and the
rationale behind them _is_ necessary even when the audience is competent
technical people.

> We shouldn't prescribe how many copies of a key one should keep where in
> which crypto containers, or whether you should use an USB thumb drive,
> smart card or a floppy to do it.

Yet, we should have the guidelines mention that permanent loss of the
key to hardware defect or bitrot is a real danger, which can be
mitigated by using more/different storage devices stored at the same
place (exposure risk control) or at diferent places (increased exposure
risk, but better at reducing data loss risk).

We can, of course, tone down the guidelines ("should" instead of "shall"
or "must"), and leave "must" to just the very few extremely important
directives.

> DD's are technically competent people and are perfectly able to decide
> what adequate protection for their private key material should look like.

You assume all DDs are technically competent on cryto, and more
specifically, on gpg-based crypto.  That is incorrect.  We're not
specialists on the same things, and that's our strength.

So let the crypto specialists write proper guidelines that the others
(Continue reading)

Ana Guerrero | 5 Nov 2011 17:49
Picon
Favicon

Help wanted for Google Code-in


Hi!

Debian has applied to the Google code-in [1] program as mentoring organization
(Thanks Algernon!) In the Google code-in, pre-university students 
(ages 13-17), have the opportunity of contributing to Debian, trying 
to complete different tasks.

[1] http://wiki.debian.org/GoogleCodeIn2011

We are hoping to get accepted and improve our outcome from last year. To
achieve this, we need the help of more Debian contributors proposing and
mentoring simple tasks for the students. Please take a take a look at the
archives in the mailing list and join us with your proposals:
http://lists.alioth.debian.org/mailman/listinfo/soc-coordination

The list of tasks is at http://wiki.debian.org/GoogleCodeIn2011/Applying, we
are specially missing translation and training tasks!

You can also join us in the IRC channel #debian-soc (irc.oftc.net)

Christian PERRIER | 5 Nov 2011 19:43
Picon
Favicon
Gravatar

Report from participation to India miniDebconf, Mangalore edition


This mail will try to summarize what I learned, discovered, shared,
etc. during my stay at the Mangalore edition of India mini DebConfs
2011 [1].

This miniDebConf is the third one scheduled this year in India. The
first one in Kuttipuram, Kerala, back in April 2011 had about 25
attendees, while the second one, in Pune, in August 2011 had up to 150
registered attendees. That followed another miniDebConf organized in
2010, in Pune [2].

This edition was organized at the NMAMIT (Nitte MahaLinga Adyanthaya
Memorial Institute of Technology) [3], about 50 kilometers north of
the coastal city of Mangalore, in the state of Karnataka, in
south-west India ([4] and [5]).

Organisation was lead by Vasudev Kamath and a very
efficient and active team of Computer Science students from the
college. This college, overall, has about 4000 students. Organization
got full support from the college staff, including the college
principal, Dr. S. Y. Kulakarni, who presided the conference inaugural
session.

My own travel to India was funded by the Debian project assets, with
approval of our respected DPL, Stefano Zacchiroli. Hosting and
accomodation for invited guests were taken care of by the organizers in
the college guest house (that covered about 15 guests as far as I have
witnessed).

I gave the opening talk, after the formal inauguration ceremony (where
(Continue reading)


Gmane