Re: Use of tokens for access to Debian resources?

[Stephen R Marenka]

On Tue, Nov 14, 2006 at 10:58:38PM +, Floris Bruynooghe wrote:

> I don't see what's so wrong with a smart card or so.  GnuPG cards do
> exist already, and is it so much to need a card reader?  If the
> project is shelling out the money anyway they could easily include the
> card readers too.

Cards are very portable, card readers much less so.

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Use of tokens for access to Debian resources?

[Stephen R Marenka]

On Wed, Nov 15, 2006 at 08:32:10AM +1100, Hamish Moffatt wrote:

> I don't think they would be trivial to replicate. The genuine RSA token is a
> small sealed card with a keypad, a display and a battery that lasts up
> to 3 years. They are small so as to be portable and convenient, which DDs 
> will demand.

The keyfob-types don't even have a keypad, just a screen which updates
every minute. You concatenate your pin to the display on the screen to
make up your password.

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Use of tokens for access to Debian resources?

[Sven Luther]

On Wed, Nov 15, 2006 at 08:32:10AM +1100, Hamish Moffatt wrote:
> On Tue, Nov 14, 2006 at 06:47:57PM +0100, Sven Luther wrote:
> > On Tue, Nov 14, 2006 at 06:38:58PM +0100, Marco d'Itri wrote:
> > > [EMAIL PROTECTED] wrote:
> > > 
> > > >I'm inclined to agree with Russell Coker[1], in that Debian should use
> > > >something like RSA tokens to control access to Debian resources.
> > > I'd love to, but I do not know any which is even close to be really
> > > free-as-in-freedom.
> > 
> > They should be trivial to produce though, if there was a budget for it,
> > especially given the relatively big amount of cash debian has on the spi 
> > bank
> > accounts.
> > 
> > A special kind of token designed for our uses, with an optional braille
> > display for example. Done as a open-source hardware project, with open 
> > source
> > hardware design tools. That would be a worthy project, and the open 
> > sourceness
> > of it could both be an example of open source hardware, and improve the
> > computer security generally.
> 
> I don't think they would be trivial to replicate. The genuine RSA token is a
> small sealed card with a keypad, a display and a battery that lasts up
> to 3 years. They are small so as to be portable and convenient, which DDs 
> will demand.

Well, the important thing is to replicate the functionality, or to implement
something different which is suited to the method we want to use. We are going
to decide how both sides of the process work, so we can adapt it to the
possibilities, and i beliee we have enough technical competences about
cryptography in debian that we could come up with something nice. I don't have
such knowledge myself though, but i have an interrest in electronics, and some
basic knowledge.

> I don't think the electronics is complicated; basically it just has a
> seed which increments every 60 seconds exactly, and to use it you key in
> your PIN. Some function of your PIN + the current seed makes your

Indeed. This is pretty trivial. We would like to replace the display by a
braille display for example.

> temporary password. The difficulty is in manufacturing something small
> and reliable.

Well, small is not very problematic, the thing is that it has to be rather
economic. Reliability is also important, but none of those are really
extremely difficuly things.

> The 60 second update does need to be accurate over the 3 year lifetime,
> because a software process at the other end has to know the current
> seed. (Often there is +/- one seed leeway). That over extremes of heat,
> cold, humidity etc which affect clock stability.

Yes, this is probably the most complicated part of the design, but as said we
can adapt the protocol a bit to handle less accurate clocks.

I know that standard RTC chips, with temperature compensations, can reach
accuraccies of 2 ppm (0-40 dgree) and upto 3.5ppm (-40 - 85 degrees), but
maybe something else can be used. 2ppm correspond to roughly a minute every
year or so, so this would be too much for the 60s max delay over 3 years,
since it would be 3 seeds at the end of the 3 year period. Not so bad though.

That said, there is another factor that may help. Even losely accurate quartz,
as those used in common clocks, can obtain a greater amount of accuracy by
keeping them at a constant temperature, namely at body temperature. I am not
sure folk would like watch-like tokens though :)

BTW, i didn't know humidity affected the clock stability, but i guess that in
a ruggedized setup, humidity should not be a problem, no ? 

Friendly,

Sven Luther
> 
> 
> Hamish
> -- 
> Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> ---
> Orange vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
> Aucun virus connu a ce jour par nos services n'a ete detecte.
> 
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Use of tokens for access to Debian resources?

[Floris Bruynooghe]

On Wed, Nov 15, 2006 at 08:32:10AM +1100, Hamish Moffatt wrote:
> I don't think they would be trivial to replicate. The genuine RSA token is a
> small sealed card with a keypad, a display and a battery that lasts up
> to 3 years. They are small so as to be portable and convenient, which DDs 
> will demand.

I don't see what's so wrong with a smart card or so.  GnuPG cards do
exist already, and is it so much to need a card reader?  If the
project is shelling out the money anyway they could easily include the
card readers too.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Position Statement to the Dunc-Tanc "experiment"

[Hans-Georg Bork]

All,

I'd like to sign the statement as well.

Hans-Georg Bork
- debian user since the early days of hamm -


signature.asc
Description: This is a digitally signed message part

Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Matt Zimmerman]

On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote:
>  * Using a different "Closes:" name, which just sidetracks the issue
>if every derivative have to use a different name, this does not
>scale. (Example: Maemo uses "Fixes:" instead of "Closes:" [1],
>and there's a proposal in Ubuntu to do something similar with
>a different name[3]).

FTR, the syntax agreed upon for Launchpad (and thus Ubuntu) is:

LP: #xxx

which is not arbitrary or ambiguous like fixes vs. closes.

> [...]
> which are wrong, ugly or may need a central registration place to avoid
> collisions either in the mnemonic or the "alternative" closure syntax.
> Probably the cleanest one is the "Closes Ubuntu:" approach.

I don't see a problem with the approach we've chosen for Launchpad (which
will also cover several Ubuntu derivatives).

Likewise, I think that qualifying it with the distribution name is perfectly
OK; that's already unique enough.

> So I'd propose to extend the changelog format to add an optional origin
> field in the header, then that information will be preserved after the
> upload. Something like this:
> 
> foo (1.0-2naibed2) quux; urgency=low, origin=naibed
> [...]

I think this is a fine idea, though orthogonal to what we're doing with
Launchpad references in changelogs.

> That origin could be matched against /etc/dpkg/origins. I'm attaching a
> PoC patch with those change to dpkg. Probably we'd not want to output the
> Origin field in the default mode (assuming Debian or local), instead of
> the current implementation which outputs "Origin: debian".  So comments
> and other proposals welcome!

I didn't see the patch, but bear in mind that it's not unusual to upload a
package to Debian from an Ubuntu system or vice versa.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Use of tokens for access to Debian resources?

[Hamish Moffatt]

On Tue, Nov 14, 2006 at 06:47:57PM +0100, Sven Luther wrote:
> On Tue, Nov 14, 2006 at 06:38:58PM +0100, Marco d'Itri wrote:
> > [EMAIL PROTECTED] wrote:
> > 
> > >I'm inclined to agree with Russell Coker[1], in that Debian should use
> > >something like RSA tokens to control access to Debian resources.
> > I'd love to, but I do not know any which is even close to be really
> > free-as-in-freedom.
> 
> They should be trivial to produce though, if there was a budget for it,
> especially given the relatively big amount of cash debian has on the spi bank
> accounts.
> 
> A special kind of token designed for our uses, with an optional braille
> display for example. Done as a open-source hardware project, with open source
> hardware design tools. That would be a worthy project, and the open sourceness
> of it could both be an example of open source hardware, and improve the
> computer security generally.

I don't think they would be trivial to replicate. The genuine RSA token is a
small sealed card with a keypad, a display and a battery that lasts up
to 3 years. They are small so as to be portable and convenient, which DDs 
will demand.

I don't think the electronics is complicated; basically it just has a
seed which increments every 60 seconds exactly, and to use it you key in
your PIN. Some function of your PIN + the current seed makes your
temporary password. The difficulty is in manufacturing something small
and reliable.

The 60 second update does need to be accurate over the 3 year lifetime,
because a software process at the other end has to know the current
seed. (Often there is +/- one seed leeway). That over extremes of heat,
cold, humidity etc which affect clock stability.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Martin Schulze]

Manoj Srivastava wrote:
> No, please don't/ It is one thing to patch dpkg to make things
>  easier for the derivatives (on the other hand, they can patch their
>  own version of dpkg), it is another to change how uplaods work in
>  Debian, or to reject uploads to Debian because one forgot add the
>  debian origin.

Another thing: Whatever you do, don't do it on stable or security builds
will end up in the void.

Regards,

Joey

-- 
Still can't talk about what I can't talk about.  Sorry.  -- Bruce Schneier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Manoj Srivastava]

On Wed, 15 Nov 2006 01:59:52 +1000, Anthony Towns
 said:  

> On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote:
>> foo (1.0-2naibed2) quux; urgency=low, origin=naibed foo
>> (1.0-2naibed1) quux; urgency=low, origin=naibed foo (1.0-2)
>> unstable; urgency=high

> Neat.

> Presumably Debian should REJECT uploads with an Origin: field other
> than "debian", no?

> Would it be more pleasant to have something like:

>> foo (1.0-2naibed1) naibed/quux; urgency=low

> instead?

> Would it be worth requiring:

>> foo (1.0-2) debian/unstable; urgency=high
> or
>> foo (1.0-2) unstable; urgency=high, origin=debian
> for Debian uploads?

No, please don't/ It is one thing to patch dpkg to make things
 easier for the derivatives (on the other hand, they can patch their
 own version of dpkg), it is another to change how uplaods work in
 Debian, or to reject uploads to Debian because one forgot add the
 debian origin.

manoj
-- 
The trouble with opportunity is that it always comes disguised as hard
work. Herbert V. Prochnow
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Use of tokens for access to Debian resources?

[Sven Luther]

On Tue, Nov 14, 2006 at 06:38:58PM +0100, Marco d'Itri wrote:
> [EMAIL PROTECTED] wrote:
> 
> >I'm inclined to agree with Russell Coker[1], in that Debian should use
> >something like RSA tokens to control access to Debian resources.
> I'd love to, but I do not know any which is even close to be really
> free-as-in-freedom.

They should be trivial to produce though, if there was a budget for it,
especially given the relatively big amount of cash debian has on the spi bank
accounts.

A special kind of token designed for our uses, with an optional braille
display for example. Done as a open-source hardware project, with open source
hardware design tools. That would be a worthy project, and the open sourceness
of it could both be an example of open source hardware, and improve the
computer security generally.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Use of tokens for access to Debian resources?

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>I'm inclined to agree with Russell Coker[1], in that Debian should use
>something like RSA tokens to control access to Debian resources.
I'd love to, but I do not know any which is even close to be really
free-as-in-freedom.

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Thomas Viehmann]

Anthony Towns wrote:
> Presumably Debian should REJECT uploads with an Origin: field other than
> "debian", no?
Might be nice, on the other hand...

> Would it be more pleasant to have something like:
>> foo (1.0-2naibed1) naibed/quux; urgency=low
> instead?

...wouldn't something like this amount to having
> Distribution: naibed/quux
in .changes. This might actually be desirable and would be already
implemented in dak?

> Would it be worth requiring:
>> foo (1.0-2) debian/unstable; urgency=high
> or
>> foo (1.0-2) unstable; urgency=high, origin=debian
> for Debian uploads?

Wouldn't the benefit be deminished by dch et al. producing changelog
entries suited for upload to Debian by default?
If derivatives change this, their packages woudln't go into Debian anyways.

Cheers

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Henrique de Moraes Holschuh]

On Tue, 14 Nov 2006, Bart Martens wrote:
> I don't think that the Debian project should lead this discussion.

We are the origin of the tools, and we are the "upstream" for them, so
*yes*, we are to be part of, and maybe even lead this discussion.

> No, I don't think that Debian is responsible for helping derivatives to
> automate the updating of the derivatives' bug tracking systems.
> 
> Don't get me wrong, there's nothing wrong with cooperating with Ubuntu
> or other derivatives.  But I think that joint efforts should make Debian
> better.  If not then I wonder if Debian should do the efforts.

It will make my life as a DD easier when maintaining my Debian packages
where I want to merge from other debian-based distros, or if we have a
cross-distro co-maintenance of a package...

This is, as usual, something we better join in so that a good-for-everyone
solution is found and implemented before it results in too many work for all
involved.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Anthony Towns]

On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote:
> foo (1.0-2naibed2) quux; urgency=low, origin=naibed
> foo (1.0-2naibed1) quux; urgency=low, origin=naibed
> foo (1.0-2) unstable; urgency=high

Neat.

Presumably Debian should REJECT uploads with an Origin: field other than
"debian", no?

Would it be more pleasant to have something like:

> foo (1.0-2naibed1) naibed/quux; urgency=low

instead?

Would it be worth requiring:

> foo (1.0-2) debian/unstable; urgency=high

or

> foo (1.0-2) unstable; urgency=high, origin=debian

for Debian uploads?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Bart Martens]

Hi Guillem,

On Tue, 2006-11-14 at 08:11 +0200, Guillem Jover wrote:
> Right now there's no clean way for a Debian derivative to close bugs
> specific to their distro in a changelog entry and then distinguish
> those from Debian bugs.

Yes, "for a Debian derivative".

> I'd like that developers from derivatives would get involved in this
> discussion 

Absolutely.  It's in the interest of the derivatives.

I don't think that the Debian project should lead this discussion.

How many derivatives currently automatically parse the changelogs to
update their bug tracking systems? Maybe only Ubuntu, I'm not sure.

> so that we can get a general solution for everyone, 

A solution for the derivative.  Or for multiple derivatives if they
agree on using the same solution.  I don't think it's a solution for
Debian.

> as I
> think Debian should be responsible for providing the infrastructure
> to do that.

No, I don't think that Debian is responsible for helping derivatives to
automate the updating of the derivatives' bug tracking systems.

Don't get me wrong, there's nothing wrong with cooperating with Ubuntu
or other derivatives.  But I think that joint efforts should make Debian
better.  If not then I wonder if Debian should do the efforts.

> So I'd propose to extend the changelog format

I have not yet studied your proposal, because I want to get some bugs
fixed before etch releases. :)

Regards,

Bart Martens



signature.asc
Description: This is a digitally signed message part