Re: Help bringing bugs.debian.org / debbugs back on track (Re: bits from the DPL -- September 2013)

[Russ Allbery]

Paul Wise  writes:

> Please don't switch bugs.debian.org away from debbugs. I don't want to
> have to leave the Debian project but some misguided folks doing that
> would be one of the triggers for that. None of the other bug tracking
> systems have anywhere near the amount of features or usability that
> debbugs has. While debbugs could definitely use more work on it, the
> current state is acceptable and definitely not a problem for Debian. I
> only wish more upstream projects and hosting sites used debbugs, then I
> might actually enjoy filing bugs upstream.

+1 to every word of this.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87siw22drn@windlord.stanford.edu

Re: Help bringing bugs.debian.org / debbugs back on track (Re: bits from the DPL -- September 2013)

[Paul Wise]

On Wed, Oct 16, 2013 at 8:51 AM, Filipus Klutiero wrote:

> However, I am not convinced that development of bugs.debian.org should go
> through Debbugs development. Unfortunately, I am not an ITS-s expert, and I
> can't recommend a particular engine. There are many free ITS engines, some
> of which are worst, but in general, as an engine user, I do not like Debbugs
> compared to most other engines. Debbugs's technology doesn't look great, but
> I'm entirely unaware of the internals. My skepticism on its future really
> comes from the current number of users and developers, and most importantly
> its advancement compared to alternatives. I can only agree that the ITS
> needs help and that Debbugs can use development, but I'm not convinced
> that's an optimal use of our currently nearly inexistent ITS manpower (see
> https://lists.debian.org/stats/debian-debbugs.png ).

Please don't switch bugs.debian.org away from debbugs. I don't want to
have to leave the Debian project but some misguided folks doing that
would be one of the triggers for that. None of the other bug tracking
systems have anywhere near the amount of features or usability that
debbugs has. While debbugs could definitely use more work on it, the
current state is acceptable and definitely not a problem for Debian. I
only wish more upstream projects and hosting sites used debbugs, then
I might actually enjoy filing bugs upstream.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gvrm2au8dyqn+-8xm88-chbswjxby40e22fy_cnxw...@mail.gmail.com

Help bringing bugs.debian.org / debbugs back on track (Re: bits from the DPL -- September 2013)

[Filipus Klutiero]

Hi Lucas,

On 2013-10-09 01:58, Lucas Nussbaum wrote:

Hi,

Here is my monthly report for September 2013 (+ the beginning of October).
Let's also use this opportunity to call for help on two key parts of our
infrastructure.

[...]


Call for help: debbugs developers
=
debbugs is the piece of software behind the Debian Bugs Tracking System
(BTS). It is also used by the GNU project[1]. Despite often being
perceived as old-style, it features several unique features, such as the
tracking of the status of bugs in each version and branch of a package
(example: [2]), or the ability to perform all interactions via email,
making it very easy to work offline or in poorly-connected environments.

Debbugs is written in Perl, its source is available from [3], there is a
testing harness available, and lists of known bugs are available from
http://bugs.debian.org/bugs.debian.org (Debian instance of debbugs) and
http://bugs.debian.org/debbugs (debbugs itself). Direct questions to the
debian-debbugs@ mailing list[4].


Thanks for bringing this up, our ITS definitely needs love. I investigated the ITS team 
in 2010 and found it was already broken (although one member disagreed with that 
assessment, qualifying the team's status as "fine"). The most urgent issue must 
be fixing the administration of bugs.debian.org, but development should also be a 
priority.

However, I am not convinced that development of bugs.debian.org should go 
through Debbugs development. Unfortunately, I am not an ITS-s expert, and I 
can't recommend a particular engine. There are many free ITS engines, some of 
which are worst, but in general, as an engine user, I do not like Debbugs 
compared to most other engines. Debbugs's technology doesn't look great, but 
I'm entirely unaware of the internals. My skepticism on its future really comes 
from the current number of users and developers, and most importantly its 
advancement compared to alternatives. I can only agree that the ITS needs help 
and that Debbugs can use development, but I'm not convinced that's an optimal 
use of our currently nearly inexistent ITS manpower (see 
https://lists.debian.org/stats/debian-debbugs.png ).

Any manpower we can find should be used as efficiently as possible, and if we won't have 
enough to keep a custom ITS going, we should consider migrating to a "COTS" 
system. A one-time effort like this may be suitable for student projects. That being 
said, we also should not underestimate the efforts needed for a proper migration: 
implementing missing features in the selected system, adapting our ITS-based tools to it 
as well as migrating the data. As you write, Debbugs has a few things which most others 
don't.

As far as I know, the suitability of Debbugs hasn't been reevaluated 
recently... if it ever was. So I simply suggest people willing to get involved 
in the ITS to have perennity in mind before investing in Debbugs.


[...]


- debbugs submissions via http (C: ? ask asheesh)


I imagine this won't be news, but this is tracked in #590269. Interesting 
project by the way (although I miss that less since I moved to reportbug-ng).

--
Filipus Klutiero
http://www.philippecloutier.com


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525de303.2020...@gmail.com

Re: Possibly moving Debian services to a CDN

[Tollef Fog Heen]

]] Ingo Jürgensmann 

> Am 14.10.2013 um 07:29 schrieb Tollef Fog Heen :
> 
> > - I would like us to have agreements with any donors that they're not
> > allowed to use the information for anything but operational issues.  We
> > can't tell them not to log (because that's really hard on a technical
> > level), but we can restrict what they can do with the logs.
> 
> True. You can request agreements, but as the whole NSA affair is
> showing: it doesn't matter when it comes down to NSA & Co. There are
> secret courts with secret decisions and National Security Letters for
> silencing the providers, although internal agreements like Safe Harbor
> do exist.
> So, whereas agreements can be made, there will be no way for Debian to 
> control whether they are being held or not.  

I'm fundamentally of the opinion that if the NSA or a similar
organisation wants to track you and is willing to expend that effort on
tracking you in particular, there is just about nothing you can do about
it.  As you note, we can't actually control it, just like we can't do it
today, so the difference becomes «lots of mirrors, vulnerable to smaller
attackers, but hard to coordinate MITM-ing» vs «fewer mirrors/CDN nodes,
requires more effort from attackers, easier to MITM».  I don't think it
makes that much of a difference in terms of cost if the attacker has
that many resources and is willing to expend the effort.  It seems you
disagree, and I don't really see us agreeing here, as it's a question of
tradeoffs and you weigh your tradeoffs differently than I do.

> >> 2) Integrity concerns: although Debian uses signed package lists and
> >> hashed packages, using a CDN would raise the chances that there might
> >> be attack vectors by manipulating the traffic. Maybe not be the will
> >> of the running company, but there are other groups that might have
> >> interest and the power to intercept traffic and manipulating it. This
> >> is, of course, also true to current mirror sites, but a centralized
> >> CDN will be more convenient to such kind of attackers.
> > Given we don't use HTTPs and such today, you don't know if the traffic
> > is actually going to the mirror you think it's going to, so this isn't
> > really different from today.  With a CDN we could actually push more of
> > the traffic to HTTPS if we wanted.  This isn't feasible with today's
> > mirror network.
> 
> That's a valid point of you, thanks! The use of HTTPS should be
> encouraged, of course. How would HTTPS with a CDN work? I would
> believe that the CDN provider will use some kind of SSL proxy or SSL
> interception techniques. Otherwise you would have the same problems
> with managing HTTPS with the current mirror network.
> There are probably these possible ways: 
> a) CDN provides an HTTPS entry point, but connects to the underlying mirror 
> by plain HTTP. 
> b) CDN uses DPI and SSL interception to break end-to-end encryption

You upload your cert and key to the CDN, which then does HTTPS to the
client.  Whether they do HTTPS to the backend or not depends on the
CDN.  I know at least some do.

[...]

> Anyway, I think the discussion about using a CDN is not about technical 
> aspects, but it's a political debate that needs to b
> held and finally a political decision have to made whether Debian as a
> Free/Libre Software project/distribution wants to use a CDN and accept
> the risks that come with that or not.

Right, there are technical hurdles we need to overcome.  If we can't
overcome those in a reasonable fashion, the whole exercise becomes
pointless.

> Personally I believe, that using a CDN would make live of DSA more
> easier (you wrote something in a different mail today that current CDN
> breaks on a weekly basis. Can you elaborate this, maybe on wiki.d.o?)
> and it might be easier for users.

The breakage I'm seeing is from apt-get update failing on various hosts
around the world.  It's usually fine if it's retried 5s later.  And yes,
the goal here is to free up volunteer time as well as get a better
experience for the end user.

> OTOH I have great privacy concerns of using a CDN. And when the
> current mirror network will still be maintained, where's the benefit
> for DSA and the users then at all? Having freedom of choice is always
> good, so I'd be fine with keeping current mirror network, but having a
> cdn.debian.org in parallel. When doing fresh installations people
> should be made aware of privacy concerns when using the CDN (like:
> "Using a CDN might be easier and faster for you, but Debian doesn't
> control the CDN and cannot guarantee privacy and data protection").

That implies we can guarantee privacy and data protection for other
mirrors, which we can't.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87siw27ibt@xoog.

Re: Possibly moving Debian services to a CDN

[Tollef Fog Heen]

]] Nikolaus Rath 

> > - You can use an IP anonymizing service such as Tor.
>  
> Are you suggesting to download debian packages over tor? Last time I
> used it, I got about 25 kB/s of bandwidth. But even if that has changed,
> I'm pretty sure the tor network isn't intended for bulk transfer of the
> debian archive...

«such as».  They're not the only one, and I wasn't suggesting running a
full mirror over it.  Downloading your daily package updates over it is
likely to be slower than your regular network connection, but when I
just tested it was at the level of some megabits.

If you're actually seriously concerned about privacy and worried about
government-level organisations using package download data for tracking
you, you should use something like tor, yes.  I personally think that's
overly paranoid, but I'm not going to tell people they're not allowed to
turn their paranoia dial all the way up.  (Using paranoia here for lack
of a better word; no disrespect meant.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqle7ito@xoog.err.no