Re: Refactoring the Debtags web interface

[Roland Mas]

Enrico Zini, 2009-02-22 23:15:36 + :

> But did I recall reading that Alioth, or debian.org, can be OpenID
> providers?  

Not currently.  Every once in a while somebody pops up and talks about
implementing an OpenID provider plugin, but it hasn't appeared yet.
If someone feels like going further, I (with my FusionForge
upstream+maintainer and Alioth hats) would be happy to provide
support, guidance and testing.

Roland.
-- 
Roland Mas

Food, shelter, source code.
  -- Cyclic Software


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re : squeeze and the future of the alpha port, redux

[Arthur Loiret]

Hi,

2009/2/20, Steve Langasek :
> Also unsurprisingly (to me, given my observations that had led to the post
> in the first place), no one else has yet stepped up to be an alpha porter
> for squeeze.

I am volunteer to apply as alpha porter. I have several alpha machines
of my own, which makes it easy to debug a failure on alpha.

> I linked to
> 
> as a starting point for folks to get involved in trying to help with the
> alpha port if they want to see it continue in squeeze.  Well, only 9 of
> those bugs have been closed in the past year, with 31 other bugs open, not
> to mention the serious problems of the port's viability implied by things
> like the lack of Java support and the general absence of a porter community.

I will have a look to them this week. Talking about upstream support,
Andrew Morton is not giving up the alpha port and always apply patches
very fast. On the gcc side, Uros Bizjak has fixed nearly all major
issues in the alpha port, and the glibc can be built with recent gcc
versions again.

I've also setup an alpha buildd to check all FTBFS (using quinn-diff),
already 138 packages built since yesterday evening :-)

> I've cc:ed everyone who listed themselves as an alpha porter for etch on
> , to make sure
> anyone willing to do the work on alpha for Squeeze has an opportunity to do
> so.  But in the absence of some demonstration of committment in the next
> couple of weeks, on March 7 I'll plan to ask the ftp team and the release
> team to drop alpha from the archive for testing and unstable.

I can provide access to some hardware if anybody else is interested in
contributing to the alpha port.

Thanks,

Arthur.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Julien BLACHE]

Sam Hartman  wrote:

Hi,

> That is, if I made the dependency in libkrb5-3.symbols look like
> libkrb5-3|libkrb53 (and similar changes for other symbols files), then
> both the packages in unstable and testing would satisfy the
> dependencies.  It seems like this would significantly reduce the
> impact of the transition.  Am I missing something or would this change
> be a good idea?

Have you considered uploading a version of krb5 with:
 - libkrb5-3
 - libkrb4-?
 - libkrb53 a metapackage depending on both of the above
 - libkrb5-dev depending on libkrb5-3 alone and containing only the
   files needed to link with libkrb5-3

Then you can do a smooth transition that won't break anything. Wait
until that version makes it to testing and then ask for binNMUs for
anything that can be binNMUed and still depends on libkrb53.

Once you're all done, get rid of libkrb4-? and libkrb53 (add a
conflict on libkrb53 in libkrb5-3 to force the removal?).

That should ease things quite a bit, especially given the number of
rdeps...

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Enrico Zini]

On Mon, Feb 23, 2009 at 11:00:06AM +1100, Ben Finney wrote:

> > and a whitelist of identity providers that every DD can easily use
> > (like alioth or debian)
> 
> What of those that use an OpenID provider not on the whitelist? (I
> imagine some not insignificant number of hackers run their own
> personal OpenID server, so an ever-expanding whitelist seems not to
> address the issue.)
> 
> What of non-DDs who do not necessarily have an account on any of those
> services, but are still valid users for authenticating in the Debtags
> system?

Fair enough, any OpenID server will probably do, as long as being
authenticated doesn't automatically authorize any privileges.

If Debian were an OpenID provider, then using the Debian OpenID could
automatically give some authorization, like assuming that one is a DD.
That could have been handy, but indeed not particularly needed.

In fact, since neither Alioth nor Debian currently can act as an OpenID
provider, this looks like the only way to go.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini 


signature.asc
Description: Digital signature

Bug#516710: ITP: libdata-pageset-perl -- Page numbering and page sets

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 

* Package name: libdata-pageset-perl
  Version : 1.05
  Upstream Author : Leo Lapworth 
* URL : http://search.cpan.org/dist/Data-Pageset/
* License : Artistic | GPL-1+ (like perl)
  Programming Lang: Perl
  Description : Page numbering and page sets

 The object produced by Data::Pageset can be used to create page navigation,
 it inherits from Data::Page and has access to all methods from this object.
 
 In addition it also provides methods for dealing with set of pages, so
 that if there are too many pages you can easily break them into chunks for
 the user to browse through.
 
 You can even choose to view page numbers in your set in a 'sliding' fassion.
 
 The object can easily be passed to a templating system such as Template
 Toolkit or be used within a script.

This package will be maintained by the pkg-perl team.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Peter Palfrader]

On Mon, 23 Feb 2009, Enrico Zini wrote:

> If Debian were an OpenID provider, then using the Debian OpenID could
> automatically give some authorization, like assuming that one is a DD.
> That could have been handy, but indeed not particularly needed.

As openid provides no security whatsoever there's probably not a big
chance of us (as in DSA) hopping onto the openid hype any time soon.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Ben Finney]

Enrico Zini  writes:

> On Mon, Feb 23, 2009 at 11:00:06AM +1100, Ben Finney wrote:
> 
> > What of those that use an OpenID provider not on the whitelist? […
> > What of non-DDs who do not necessarily have an account on any of those
> > services […]?
> 
> Fair enough, any OpenID server will probably do, as long as being
> authenticated doesn't automatically authorize any privileges.
> 
> If Debian were an OpenID provider, then using the Debian OpenID
> could automatically give some authorization, like assuming that one
> is a DD. That could have been handy, but indeed not particularly
> needed.

To be clear:

I am very much in favour of an OpenID presented for each Debian
account, just as every DD gets a debian.org email address. They would,
as you say, be very handy for use as a Debian-specific identity if the
person wants to use it.

But I'm equally against *requiring* that anyone must use a specific
provider's OpenID for general use on Debian machines, just as we don't
require a debian.org email address be used for general Debian project
use.

-- 
 \ “We are all agreed that your theory is crazy. The question that |
  `\  divides us is whether it is crazy enough to have a chance of |
_o__)being correct.” —Niels Bohr (to Wolfgang Pauli), 1958 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#516659: ITP: w3bfukk0r -- scan webservers for hidden directories (forced browsing)

[Bjørn Mork]

Noah Slater  writes:
> On Sun, Feb 22, 2009 at 05:18:39PM -0800, Asheesh Laroia wrote:
>> I think that the description explains that the purpose is to find hidden
>> directories on web servers, presumably either your own or other people's.
>
> Why would you need to find directories on your own server?

Why would you need to buy a gadget like http://www.keyringer.com/ ?


Bjørn
-- 
Let me tell you something, you capitalist, Napoleon is just a figment
of your imagination


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#516659: ITP: w3bfukk0r -- scan webservers for hidden directories (forced browsing)

[Nico Golde]

Hi,
* Don Armstrong  [2009-02-23 10:07]:
> On Mon, 23 Feb 2009, Paul Wise wrote:
[...] 
> It'd also be best if this package didn't refer to invented terminology
> like "forced browsing" and instead said what it actually does (return
> the subset of HEAD requests that return 200 from a generated
> wordlist).

http://www.owasp.org/index.php/Forced_browsing

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpUc7Mh2oQMT.pgp
Description: PGP signature

Re: Refactoring the Debtags web interface

[Ben Finney]

Peter Palfrader  writes:

> On Mon, 23 Feb 2009, Enrico Zini wrote:
> 
> > If Debian were an OpenID provider, then using the Debian OpenID
> > could automatically give some authorization, like assuming that
> > one is a DD. That could have been handy, but indeed not
> > particularly needed.
> 
> As openid provides no security whatsoever

Just like an email address, an OpenID is good for identity; security
needs to be dealt with in a separate layer, just as with email. I
don't know who promised OpenID “provides security”, or expects it.

> there's probably not a big chance of us (as in DSA) hopping onto the
> openid hype any time soon.

Given that we willingly use email for identity, despite the fact that
email provides no security, I don't see how this is anything but a
non-sequitur.

-- 
 \“I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__) Friday. That way you still have the weekend.” —Steven Wright |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Peter Palfrader]

On Mon, 23 Feb 2009, Ben Finney wrote:

> > As openid provides no security whatsoever
> 
> Just like an email address, an OpenID is good for identity; security
> needs to be dealt with in a separate layer, just as with email. I
> don't know who promised OpenID ???provides security???, or expects it.

What's the point of an identity if you can't rely on it to be really
that identity?  Authentication that is trivally bypassed or forged is
not really useful.  You might just as well accept any random username
without the whole protocol stack.
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Ben Finney]

Peter Palfrader  writes:

> What's the point of an identity if you can't rely on it to be really
> that identity? Authentication that is trivally bypassed or forged is
> not really useful.

This thread [0] isn't the place to debate how useful OpenID is for
those who choose to use it.

I invite anyone interested in knowing how the distinct areas of
identity, trust, and security intersect with the OpenID system, to
research the available documentation.


[0] Not least because we're talking about adding OpenID authentication
to an entirely optional service that is currently used quite happily
by people without *any* assurance of identity, let alone security.

-- 
 \“If you ever drop your keys into a river of molten lava, let |
  `\ 'em go, because, man, they're gone.” —Jack Handey |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Sam Hartman]

> "Julien" == Julien BLACHE  writes:

Julien> Sam Hartman  wrote: Hi,

>> That is, if I made the dependency in libkrb5-3.symbols look
>> like libkrb5-3|libkrb53 (and similar changes for other symbols
>> files), then both the packages in unstable and testing would
>> satisfy the dependencies.  It seems like this would
>> significantly reduce the impact of the transition.  Am I
>> missing something or would this change be a good idea?

3Julien> Have you considered uploading a version of krb5 with: -
Julien> libkrb5-3 - libkrb4-?  - libkrb53 a metapackage depending
Julien> on both of the above - libkrb5-dev depending on libkrb5-3
Julien> alone and containing only the files needed to link with
Julien> libkrb5-3

That's undesirable because building without krb4 has some fairly
significant impacts on non-library parts of the krb5 packages.  So I
could not actually build with krb4 support disabled.  I guess I could
do two build passes one with krb4 support and one without (picking up
only the krb4 library from the krb4 build pass).


If I do something like this why do I want the krb4 libs to end up in a
new package we plan to get rid of reasonably soon?  Why not stick them
directly in libkrb53?  (krb4 libs in libkrb53 vs libkrb4-2 seems like
aa mostly asthetic issue unless I'm missing something).


Assuming that alternatives in the symbols file works, it seems like
the only difference between your proposal and my original proposal is
that it handles uninstalling libkrb53 somewhat better if one of the
packages that replaces files in libkrb53 is installed. It also allows
the new krb5 to migrate to testing ahead of waiting for everything to
be rebuilt.  If the alternatives approach works it means that both
approaches allow other packages to migrate to testing.

If there is some problem with the alternatives approach, then your approach is 
a clear winner.  

I actually think allowing the new krb5 package to migrate to testing
is worth a second build pass on the krb5 package, so I'll do roughly
what you suggest.  I assume that with this approach I don't need to
block on anyone for the first upload (the one with libkrb53 still
present) and can do so at my convenience.

I would appreciate your input on whether there is a good reason to
stick libkrb4 in a new package vs sticking it in libkrb53.  I'd also
appreciate your answer to whether the alternatives approach would work
to help sanity check my understanding in this space.


Thanks,

--Sam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Sam Hartman]

> "Sam" == Sam Hartman  writes:

> "Julien" == Julien BLACHE  writes:
Julien> Sam Hartman  wrote: Hi,

>>> That is, if I made the dependency in libkrb5-3.symbols look
>>> like libkrb5-3|libkrb53 (and similar changes for other symbols
>>> files), then both the packages in unstable and testing would
>>> satisfy the dependencies.  It seems like this would
>>> significantly reduce the impact of the transition.  Am I
>>> missing something or would this change be a good idea?

Sam> 3 Julien> Have you considered uploading a version of krb5
Sam> with: -
Julien> libkrb5-3 - libkrb4-?  - libkrb53 a metapackage depending
Julien> on both of the above - libkrb5-dev depending on libkrb5-3
Julien> alone and containing only the files needed to link with
Julien> libkrb5-3

Sam> That's undesirable because building without krb4 has some
Sam> fairly significant impacts on non-library parts of the krb5
Sam> packages.  So I could not actually build with krb4 support
Sam> disabled.  I guess I could do two build passes one with krb4
Sam> support and one without (picking up only the krb4 library
Sam> from the krb4 build pass).


Sam> unless I'm missing something).


Sam> Assuming that alternatives in the symbols file works, it
Sam> seems like the only difference between your proposal and my
Sam> original proposal is that it handles uninstalling libkrb53
Sam> somewhat better if one of the packages that replaces files in
Sam> libkrb53 is installed. It also allows the new krb5 to migrate
Sam> to testing ahead of waiting for everything to be rebuilt.  If
Sam> the alternatives approach works it means that both approaches
Sam> allow other packages to migrate to testing.

Ah, I was missing something.  It allows us to decouple when we
generate a bunch of binary NMUs from when we turn off krb4.  When I
upload the new package, nothing breaks in unstable, so there is no
particular need for the release team to do anything under any time
pressure.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#516750: ITP: rsplib -- Implementation of the IETF's Reliable Server Pooling (RSerPool) standard defined in RFCs 5351 to 5356.

[Thomas Dreibholz]

Package: wnpp
Severity: wishlist
Owner: Thomas Dreibholz 


* Package name: rsplib
  Version : 2.6.0
  Upstream Author : Thomas Dreibholz 
* URL : http://tdrwww.iem.uni-due.de/dreibholz/rserpool/
* License : GPL version 3
  Programming Lang: C, C++
  Description : Implementation of the IETF's Reliable Server Pooling 
(RSerPool) standard defined in RFCs 5351 to 5356.

RSPLIB is the Open Source implementation (GPLv3) of the IETF's standard for
Reliable Server Pooling (RSerPool). RSerPool is a framework for server pool
management and access. It is an IETF standard, which has been developed by
the IETF RSerPool Working Group and documented in RFC 5351 to RFC 5356. From
the programmer's perspective, a pool is mainly seen as a highly available
server. RSerPool realizes a Session Layer in the OSI model. The API to
access this Session  Layer is very similar to TCP/IP socket programming, so
using RSerPool functionalities in own programs is quite easy. If you are
looking for a simple-to-use workload distribution system including failover
capabilities, but without the overhead and configuration effort of GRID
computing, RSPLIB is probably what you are looking for! A lot of documents
on RSerPool and  RSPLIB can be found on the project homepage at:
http://tdrwww.iem.uni-due.de/dreibholz/rserpool/ .

RSPLIB is already included in Ubuntu Intrepid and Jaunty. Therefore, I
would like to add it to Debian, too.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/r/rsplib
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/r/rsplib/rsplib_2.6.0-1.dsc



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Julien BLACHE]

Sam Hartman  wrote:

Hi,

> Julien> Have you considered uploading a version of krb5 with: -
> Julien> libkrb5-3 - libkrb4-?  - libkrb53 a metapackage depending
> Julien> on both of the above - libkrb5-dev depending on libkrb5-3
> Julien> alone and containing only the files needed to link with
> Julien> libkrb5-3
>
> That's undesirable because building without krb4 has some fairly
> significant impacts on non-library parts of the krb5 packages.  So I
> could not actually build with krb4 support disabled.  I guess I could
> do two build passes one with krb4 support and one without (picking up
> only the krb4 library from the krb4 build pass).

Hmm. Can't you just continue to build like you do today and separate
the two libraries? Is there a problem with doing that?

I don't know the details on the krb5 packaging, but separating out the
libraries doesn't look like a big deal. As you'll be keeping libkrb53
and add a dependency on libkrb5-3, you are covered dependency-wise, if
that's an issue.

> If I do something like this why do I want the krb4 libs to end up in a
> new package we plan to get rid of reasonably soon?  Why not stick them
> directly in libkrb53?  (krb4 libs in libkrb53 vs libkrb4-2 seems like
> aa mostly asthetic issue unless I'm missing something).

Oh yeah absolutely. I wasn't sure what was your plan on that, as you
were mentionning a libkrb53 split.

> Assuming that alternatives in the symbols file works, it seems like
> the only difference between your proposal and my original proposal is
> that it handles uninstalling libkrb53 somewhat better if one of the
> packages that replaces files in libkrb53 is installed. It also allows

Yes; libkrb5-3 will have a Replaces: libkrb53 right from the start,
and when you'll drop krb4 you can just drop libkrb53 altogether and
add the Conflicts: libkrb53 to libkrb5-3. That will take care of
eliminating libkrb53 and will also cover upgrades quite nicely.

> the new krb5 to migrate to testing ahead of waiting for everything to
> be rebuilt.  If the alternatives approach works it means that both
> approaches allow other packages to migrate to testing.

As you note in your second reply, the goal is to decouple the
packaging change from the krb4 dismissal:
 1 introduce libkrb5-3 (Replaces: libkrb53), with libkrb53 depending
   on libkrb5-3, libkrb5-3.shlibs pointing to libkrb53, and a
   versionned dependency on libkrb53 in libkrb5-dev

 2 once it hits testing, change libkrb5-3.shlibs to point to
   libkrb5-3, version the libkrb53 -> libkrb5-3 dependency and the
   libkrb5-dev -> libkrb53 accordingly

 3 once this latter version is built & installed everywhere in
   unstable, you can schedule the binNMUs for all the rdeps

 4 nobody uses libkrb53 anymore, you can drop it, drop krb4, add
   Conflicts: libkrb53 to libkrb5-3 and make libkrb5-dev depend on
   libkrb5-3

If you don't do (1), you risk being tied into other transitions by
your rdeps as they'll be picking up dependencies on libkrb5-3 as they
get uploaded in unstable as part of their own transitions or
development cycles.

Then (2) is the real thing, and once it's available everywhere in
unstable, you're good to go for the rebuilds of your rdeps.

In (2), you can also change libkrb5-dev to depend on libkrb5-3 instead
of libkrb53. By doing so, you'll be breaking the two problematic krb4
users, so you may want to wait a bit for that, eventually.

Until (4) happens, the problematic packages still using krb4 can still
be built and migrate to testing. That buys some more time for their
maintainers and avoid locking them out of testing, potentially
blocking other transitions.

Apart from scheduling the binNMUs, the release team shouldn't have to
care about your transition too much.

libkrb53 must be the tip of the iceberg, anything that happens below
the surface must not break other packages until (4).

(hope I haven't missed anything in the above, I've been careful in
considering every case I could think of)

> If there is some problem with the alternatives approach, then your
> approach is a clear winner.  

I'm not sure the alternatives approach behaves nicely on upgrade :|

> what you suggest.  I assume that with this approach I don't need to
> block on anyone for the first upload (the one with libkrb53 still
> present) and can do so at my convenience.

Yes, as long as libkrb53 remains stable and builds in unstable still
produce dependencies on libkrb53, you're not affecting anyone.

> I would appreciate your input on whether there is a good reason to
> stick libkrb4 in a new package vs sticking it in libkrb53.  I'd also

As you noted, krb4 is going away, so introducing a new package is not
worth it at this point. I was mentionning a libkrb4-? package because
you wrote in your mail that you were planning to split out the
libraries in individual packages.

> appreciate your answer to whether the alternatives approach would work
> to help sanity check my understanding in this space.

Alt

Re: Re : squeeze and the future of the alpha port, redux

[maximilian attems]

On Mon, Feb 23, 2009 at 09:59:31AM +0100, Arthur Loiret wrote:
> 
> 2009/2/20, Steve Langasek :
> > Also unsurprisingly (to me, given my observations that had led to the post
> > in the first place), no one else has yet stepped up to be an alpha porter
> > for squeeze.
> 
> I am volunteer to apply as alpha porter. I have several alpha machines
> of my own, which makes it easy to debug a failure on alpha.

no only due to the demand post release,
it is good to rethink the end of life of alpha.
 
> > I've cc:ed everyone who listed themselves as an alpha porter for etch on
> > , to make sure
> > anyone willing to do the work on alpha for Squeeze has an opportunity to do
> > so.  But in the absence of some demonstration of committment in the next
> > couple of weeks, on March 7 I'll plan to ask the ftp team and the release
> > team to drop alpha from the archive for testing and unstable.
> 
> I can provide access to some hardware if anybody else is interested in
> contributing to the alpha port.

it be cool to have a kernel alpha buildserver so that alpha
get autobuild before upload.

i'd volounteer in refreshing the config settings for alpha on linux-2.6
side, they haven't seen care for quite some time.

kind regards

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Sam Hartman]

> "Julien" == Julien BLACHE  writes:

I really appreciate your help here!

Julien> As you note in your second reply, the goal is to decouple
Julien> the packaging change from the krb4 dismissal: 1 introduce
Julien> libkrb5-3 (Replaces: libkrb53), with libkrb53 depending on
Julien> libkrb5-3, libkrb5-3.shlibs pointing to libkrb53, and a
Julien> versionned dependency on libkrb53 in libkrb5-dev

Julien>  2 once it hits testing, change libkrb5-3.shlibs to point
Julien> to libkrb5-3, version the libkrb53 -> libkrb5-3 dependency
Julien> and the libkrb5-dev -> libkrb53 accordingly
Julien> If you don't do (1), you risk being tied into other
Julien> transitions by your rdeps as they'll be picking up
Julien> dependencies on libkrb5-3 as they get uploaded in unstable
Julien> as part of their own transitions or development cycles.

I'm sorry, but I don't see how I get stuck in unstable if I start out
with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3
rather than libkrb53.  As I understand it, rdeps can only hold me in
unstable if moving my package into testing would make them
uninstallable in testing.

They depend on libkrb53  with a versioned dependency today.
A version of libkrb53 that is greater than any existing versioned dependency 
will be in my package migrating from unstable to testing, so their versioned 
dependency will be satisfied.
I don't know if we do build-dep related blocking today or not, but the 
build-deps on libkrb5-dev will continue to work.

In addition, since libkrb53 will pull in all the krb5 libraries a
package that depends on it will actually get the libraries it needs to function.

Now, I might hold my rdeps in unstable if for some reason it takes a
while for the new krb5 to migrate into testing.  However that's no
more true than if I added some symbols to one of my libraries and
upgraded my versioned dependency.  Still that's a reason to leave the
shlibs and symbols files pointing at libkrb53 until I make it into
testing.

The krb4 using packages are all leaf packages, so they will not
complicate things until libkrb53 goes away.


I trimmed the reply text, but you asked why I need two build passes.
The krb5 package includes a bunch of libraries as well as daemons,
utilities etc.  Building with krb4 enabled does more than build krb4
libraries, and I want to get the affects of building with krb4
disabled for daemons and utilities.  Doing two build passes will be
easy given my package structure and the package does not take
particularly long to build.

--Sam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Julien BLACHE]

Sam Hartman  wrote:

> I really appreciate your help here!

Thanks!

> I'm sorry, but I don't see how I get stuck in unstable if I start out
> with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3
> rather than libkrb53.  As I understand it, rdeps can only hold me in
> unstable if moving my package into testing would make them
> uninstallable in testing.

Yes you are right about this.

> Now, I might hold my rdeps in unstable if for some reason it takes a
> while for the new krb5 to migrate into testing.  However that's no

And that's what what I had in mind and wrote the other way around :)

> more true than if I added some symbols to one of my libraries and
> upgraded my versioned dependency.  Still that's a reason to leave the
> shlibs and symbols files pointing at libkrb53 until I make it into
> testing.

It's not strictly necessary as you pointed out, but in the end it
makes the transition even smoother and protects against anything that
could come up in the 10 days you'll spend in unstable with the new
version.

A bit over-engineered maybe, but I like doing transitions (and not
only package transitions in Debian :)) in a way that provides me with
a big switch to throw once everything is ready while still having
options for pausing or backing out if anything comes up.

> The krb4 using packages are all leaf packages, so they will not
> complicate things until libkrb53 goes away.

That's what I got from your initial mail.

> I trimmed the reply text, but you asked why I need two build passes.
> The krb5 package includes a bunch of libraries as well as daemons,
> utilities etc.  Building with krb4 enabled does more than build krb4
> libraries, and I want to get the affects of building with krb4
> disabled for daemons and utilities.  Doing two build passes will be

Oh, OK. That doesn't necessarily have to be done when introducing
libkrb5-3, but that's entirely your call of course.

> easy given my package structure and the package does not take
> particularly long to build.

That's a big help in this case!

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Julien BLACHE]

Sam Hartman  wrote:

Hi,

> OK, so I think we're all set.
>
> The plan now is  to 

Looks good!

> 1) Build twice, once into build and once into build-krb4.  We only
> pull libkrb4.so out of build-krb4.  2) Move all the libraries out of
> libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying
> a bit) except for libkrb4.so.2.

I guessed that looking at the various packages :)

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

[Sam Hartman]

OK, so I think we're all set.

The plan now is  to 

1) Build twice, once into build and once into build-krb4.  We only
pull libkrb4.so out of build-krb4.  2) Move all the libraries out of
libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying
a bit) except for libkrb4.so.2.

3) Make libkrb53 depend on all the libraries it now contains and libkadm55 
depend on the libraries it contains.


4) Set up symbols and shlibs files to point everyone at libkrb53 and
   libkadm55 as appropriate.



At some point after the new krb5 enters testing:

5) Point symbols  files at libkrb5-3 and friends--point them at the
   package that contains the library.




When the first release of krb5 1.7 enters debian (probably beta1):


6) Drop libkrb53 (and thus the libkrb4.so.2), libkadm55 from the
   package.  If the old krb4 library fails to work against the new
   libkrb5-3 in 1.7, add a conflicts line.  Otherwise leave the
   conflicts line off for now.


At some point later, add a conflicts line if we did not do so in step 6.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#516659: ITP: w3bfukk0r -- scan webservers for hidden directories (forced browsing)

[Noah Slater]

On Mon, Feb 23, 2009 at 01:06:38PM +0100, Bjørn Mork wrote:
> Noah Slater  writes:
> > On Sun, Feb 22, 2009 at 05:18:39PM -0800, Asheesh Laroia wrote:
> >> I think that the description explains that the purpose is to find hidden
> >> directories on web servers, presumably either your own or other people's.
> >
> > Why would you need to find directories on your own server?
>
> Why would you need to buy a gadget like http://www.keyringer.com/ ?

Because you can loose your keys.

How can you loose a directory on a machine you have access to?

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ucf: Diversion of /u/b/ucf by etcgit

[Frank Küster]

Jörg Sommer  wrote:

>>> But I can get the files dpkg installs in /etc. That's enough for the
>>> first step. I don't want to create an AI that does everything right. One
>>> step after the other!
>>
>> No, dpkg installs _nothing_ in /etc for ucf related files
>
> Right, but your are mixing two different things.

NO, you don't seem to understand what ucf is for, and is doing.

> (1) I use the
> hooks provided by apt to get the original files from the
> package

In other words, with ucf you get NOTHING, since there are no original
files in the package. They are only created temporarily while postinst
is run. 

Regards, Frank
-- 
Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ucf: Diversion of /u/b/ucf by etcgit

[sean finney]

On Mon, Feb 23, 2009 at 09:24:17PM +0100, Frank Küster wrote:
> > (1) I use the
> > hooks provided by apt to get the original files from the
> > package
> 
> In other words, with ucf you get NOTHING, since there are no original
> files in the package. They are only created temporarily while postinst
> is run. 

i think what you really want[1] is something mentioned earlier back in
the thread, where ucf provides a set of run-hooks that you could
exploit for the purposes of tracking files,  thus eliminating
the need for diverting ucf at all.


sean

[1] i make no claims of being psychic or clairvoyant of course


signature.asc
Description: Digital signature

Bug#516835: ITP: libgstreamer-interfaces-perl -- Perl interface to the GStreamer Interfaces library

[Antonio Radici]

Package: wnpp
Severity: wishlist
Owner: Antonio Radici 



* Package name: libgstreamer-interfaces-perl
  Version : 0.04
  Upstream Author : Torsten Schönfeld 
* URL : http://search.cpan.org/dist/GStreamer-Interfaces/
* License : GPL-1+ | Artistic
  Programming Lang: Perl
  Description : Perl interface to the GStreamer Interfaces library

libgstreamer-interfaces-perlprovides access to some of the interfaces 
in the GStreamer Interfaces library. Currently, that's 
GStreamer::PropertyProbe and GStreamer::XOverlay 
.
The perl bindings follow the C API very closely, and the C reference
documentation should be considered the canonical source.
.
This module is part of gtk2-perl.
.
To discuss gtk2-perl, ask questions and flame/praise the authors,
join gtk-perl-l...@gnome.org at lists.gnome.org.
.
Also have a look at the gtk2-perl website and sourceforge project page,
http://gtk2-perl.sourceforge.net

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#516415: ITP: skysentials -- extra functionalities for Skype Linux client

[Rafael Laboissiere]

* Hendrik Sattler  [2009-02-21 16:43]:

> Am Samstag 21 Februar 2009 11:29:19 schrieb Rafael Laboissiere:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Rafael Laboissiere 
> >
> > * Package name: skysentials
> >   Version : 1.0.1
> >   Upstream Author : Philipp Kolmann 
> > * URL : http://www.kolmann.at/philipp/linux/skysentials/
> > * License : BSD
> >   Programming Lang: Python
> >   Description : Extra functionalities for Skype Linux client
> [...]
> > Architecture: amd64 (x86_64)
> 
> 
> That is strange: you depend on a package that is neither in Debian nor 
> available for amd64 (skype.com only offer i386).

Yes you are right, this is not appropriate.  Changing the Depends to a
Suggests would be acceptable, or perhaps not having a relationship to skype
at all.  Unfortunately, I already uploaded the package and it is NEW now.
Let us see what the ftp-master admins will say.
 
-- 
Rafael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Brian May]

Peter Palfrader wrote:

As openid provides no security whatsoever there's probably not a big
chance of us (as in DSA) hopping onto the openid hype any time soon.
  


openid could be secure - e.g. by enforcing https everywhere, always 
checking the remote certificate properly, never using passwords for 
authentication, etc.


Unfortunately, none of these apply to the implementations I have seen 
(although my openid provider does at least allow for x509 certificate 
authentication instead of password passed authentication).


There was a good article at 
, 
unfortunately the domain appears to be off-line now, and the archive at
 
is difficult to read due to bad formatting.


--
Brian May 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Brian May]

Ben Finney wrote:

I invite anyone interested in knowing how the distinct areas of
identity, trust, and security intersect with the OpenID system, to
research the available documentation.
  


...except openid has serious issues with establishing identity in a 
secure manner. Especially if the server connects to your identity 
provider using http (seems to be common practise as far as I can tell). 
Using http makes MITM attack easy. Just redirect requests to an identity 
provider that always confirms the user's identity. Even if https is 
used, does the server validate the CA certificate? I have seen openid 
server software that doesn't do any checking of the SSL certificate (yes 
there is a bug report on the issue).


Even then it is possible that a malicious website will redirect you to a 
website that looks identical to your identity provider's website, asks 
for you password, and then steals it.


Sure, an alert user will notice this; Unfortunately many users would not 
notice.


If you can't establish identity in a secure manner, you can't establish 
trust, authorisation, or security in a secure manner either.


The key issue seems to be that openid wasn't designed from the ground up 
to be secure; for a secure solution you need something like Shibboleth 
 
 (which I have been told *is* more 
secure) or maybe even a solution that
requires web browser client support (e.g. Kerberos or something like 
Kerberos).


--
Brian May 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Sam Hartman]

> "Brian" == Brian May  writes:

Brian> Ben Finney wrote:
>> I invite anyone interested in knowing how the distinct areas of
>> identity, trust, and security intersect with the OpenID system,
>> to research the available documentation.
>> 

Brian> ...except openid has serious issues with establishing
Brian> identity in a secure manner. Especially if the server
Brian> connects to your identity provider using http (seems to be
Brian> common practise as far as I can tell). Using http makes
Brian> MITM attack easy. Just redirect requests to an identity
Brian> provider that always confirms the user's identity. 

I find it deeply ironic that I'm arguing against security.  However,
let's remember that we're talking about debtags.  It's always
important to think about your threat model and about how much
complexity you're willing to spend in order to get security.

This seems like a case where usability is far more important than
security.  If the system starts getting abused, we can lock it down
more.

If someone proposed using openid to do debian.org password resets or
to maintain the keyring, I'd be screaming up and down all over the
place.  I just don't see that the value of attacking the debtags
system warrents increased complexity and decreased usability in this
instance.

--Sam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Refactoring the Debtags web interface

[Peter Palfrader]

On Mon, 23 Feb 2009, Sam Hartman wrote:

> I find it deeply ironic that I'm arguing against security.  However,
> let's remember that we're talking about debtags.  It's always
> important to think about your threat model and about how much
> complexity you're willing to spend in order to get security.

For debtags I completely agree.  But I was arguing against openid
because people were asking for ud-ldap/db.debian.org be turned into an
openid provider to be used for everything webish on debian.org,
including db.d.o.
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#516873: ITP: xfconf -- utilities for managing settings in Xfce

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: xfconf
  Version : 4.6.0
  Upstream Author : Brian J. Tarricone 
Stephan Arts 
* URL : http://www.xfce.org/
* License : GPL-2
  Programming Lang: C
  Description : utilities for managing settings in Xfce

xfconf is a settings manager for Xfce, based on D-Bus. There is a daemon
(xfconfd) and a library to access settings stored there (libxfconf). A
command line tool (xfconf-query) is provided too.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#516415: ITP: skysentials -- extra functionalities for Skype Linux client

[Neil Williams]

On Tue, 24 Feb 2009 00:15:37 +0100
Rafael Laboissiere  wrote:

> > > Architecture: amd64 (x86_64)
> > 
> > 
> > That is strange: you depend on a package that is neither in Debian nor 
> > available for amd64 (skype.com only offer i386).
> 
> Yes you are right, this is not appropriate.  Changing the Depends to a
> Suggests would be acceptable, or perhaps not having a relationship to skype
> at all.  Unfortunately, I already uploaded the package and it is NEW now.
> Let us see what the ftp-master admins will say.

Or just bump the Debian version with the change you need and re-upload
to NEW - you can have more than one version in NEW at a time and only
the highest version will actually make it into the archive.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpwma7VpGNph.pgp
Description: PGP signature

Bug#516878: ITP: xfce4-settings -- graphical applications for managing Xfce settings

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: xfce4-settings
  Version : 4.6.0
  Upstream Authors: Stephan Arts 
Brian J. Tarricone 
Jannis Pohlmann 
* URL : http://www.xfce.org/
* License : GPL-2+
  Programming Lang: C
  Description : graphical applications for managing Xfce settings

xfce4-settings contains:
- xfce4-settings-manager (control center)
- xfce4-settings-helper: a daemon which provides special features, like 
  keyboard shortcuts,  AccessX notification and update of keyboard and 
  mouse-pointer data
- xfce4-settings-editor, a tool for editing ALL settings within xfconf

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#516875: ITP: libxfce4menu -- freedesktop.org compliant menu implementation for Xfce

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: libxfce4menu
  Version : 4.6.0
  Upstream Author :  Jannis Pohlmann 
* URL : http://www.xfce.org.org/
* License : GPL-2+
  Programming Lang: C
  Description : freedesktop.org compliant menu implementation for Xfce

libxfce4menu is an XDG-compliant menu implementation for Xfce Desktop
Environment.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org