Re: Please respect Freeze Policy

[Didier 'OdyX' Raboud]

Le jeudi, 4 décembre 2014, 07.46:25 Bart Martens a écrit :
> On Wed, Dec 03, 2014 at 10:42:54AM +0100, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit :
> > > Would it be OK to abuse experimental for new upstreams during
> > > freeze?
> > 
> > during freezes, where unstable should only have changes targeted at
> > testing (and therefore, currently, at jessie).
> 
> I don't read that in the freeze policy. Do you?

It's indeed not mentioned there, although the following paragraph is of 
interest:

> If the version in unstable has significant changes that cannot be
> reversed or stuck behind other packages that are not acceptable,
> please contact the release team (i.e. file a bug) for doing your
> upload to testing-proposed-updates. However, please remember that
> stricter rules apply to testing-proposed-updates (see here for the
> rules.)

The November Bits from the release team [0] have a different phrasing 
too :
> Uploads to unstable
> 
> Since many updates (hopefully, the vast majority) will be via
> unstable, changes there can be disruptive if they would be unsuitable
> for Jessie.
> Please be mindful of this, particularly if you maintain a library or
> key package.

My understanding of the situation is that the Release Team considers 
unstable to be the ante-chamber of testing, and that they expect it to 
only contain changes suitable for inclusion in the next stable release.

The problem with new upstream releases in unstable during the freeze is 
not these uploads /per se/, but with what they "inflict" on related 
packages and on testing. As others have mentioned in this thread:

* RC bugs discovered in the testing version of the package ?
  ↳ Needs to go through t-p-u
* Package is used in Build-Depends of other packages ?
  ↳ Other packages need to go through t-p-u

So, of course, the heart of the problem is the insufficient usage of t-
p-u by users, leading to /de facto/ uploads straight to testing. But 
this isn't easily solved: we already have three major suites and 
documenting all the additional partial suites in ways that make users 
_want_ to use these (and report bugs they see) isn't easy. Many of us 
developers are users of unstable: having this suite as close to testing 
as possible (especially during freezes) is _good_ for the quality of our 
stable releases.

I'd encourage the RT to push even more for an 'unstable' suite dedicated 
to the release process. Development can perfectly "continue" in 
experimental.

Cheers,
OdyX

[0] https://lists.debian.org/debian-devel-announce/2014/11/msg3.html

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

Re: Please respect Freeze Policy

[Bart Martens]

On Thu, Dec 04, 2014 at 10:00:38AM +0100, Didier 'OdyX' Raboud wrote:
> Le jeudi, 4 décembre 2014, 07.46:25 Bart Martens a écrit :
> > On Wed, Dec 03, 2014 at 10:42:54AM +0100, Didier 'OdyX' Raboud wrote:
> > > Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit :
> > > > Would it be OK to abuse experimental for new upstreams during
> > > > freeze?
> > > 
> > > during freezes, where unstable should only have changes targeted at
> > > testing (and therefore, currently, at jessie).
> > 
> > I don't read that in the freeze policy. Do you?
> 
> It's indeed not mentioned there,

OK, then let's not imagine a rule that isn't in there. :-)

> although the following paragraph is of 
> interest:
> 
> > If the version in unstable has significant changes that cannot be
> > reversed or stuck behind other packages that are not acceptable,
> > please contact the release team (i.e. file a bug) for doing your
> > upload to testing-proposed-updates. However, please remember that
> > stricter rules apply to testing-proposed-updates (see here for the
> > rules.)

That is from "how to get an unblock". And, the entire text of the freeze policy
is "of interest". :-)

> 
> The November Bits from the release team [0] have a different phrasing 
> too :
> [0] https://lists.debian.org/debian-devel-announce/2014/11/msg3.html
> > Uploads to unstable
> > 
> > Since many updates (hopefully, the vast majority) will be via
> > unstable, changes there can be disruptive if they would be unsuitable
> > for Jessie.
> > Please be mindful of this, particularly if you maintain a library or
> > key package.

This phrasing fully corresponds to the freeze policy.

> 
> My understanding of the situation is that the Release Team considers 
> unstable to be the ante-chamber of testing,

Yes, this matches with the freeze policy.

> and that they expect it to 
> only contain changes suitable for inclusion in the next stable release.

I thought that the freeze policy was meant to state what they expect. :-) It
seems you're overlooking the nuance on "disruptive" in the freeze policy.

> 
> The problem with new upstream releases in unstable during the freeze is 
> not these uploads /per se/,

I agree.

> but with what they "inflict" on related 
> packages and on testing.

This is the "disruptive" aspect as mentioned in the freeze policy.

> As others have mentioned in this thread:
> 
> * RC bugs discovered in the testing version of the package ?
>   ↳ Needs to go through t-p-u
> * Package is used in Build-Depends of other packages ?
>   ↳ Other packages need to go through t-p-u

The freeze policy states how and when to go via testing-proposed-updates.

> 
> So, of course, the heart of the problem is the insufficient usage of t-
> p-u by users, leading to /de facto/ uploads straight to testing. But 
> this isn't easily solved: we already have three major suites and 
> documenting all the additional partial suites in ways that make users 
> _want_ to use these (and report bugs they see) isn't easy.

That is, in my opinion a different problem. (I'm not rejecting this, on the
contrary, but I prefer to discuss this in a separate thread.)

The heart of the problem we're discussing here is that people with the best
intentions sometimes accidentally misread the freeze policy.

> Many of us 
> developers are users of unstable: having this suite as close to testing 
> as possible (especially during freezes) is _good_ for the quality of our 
> stable releases.

This is not in the freeze policy. It's a preference of those developers using
unstable. (I'm not rejecting this, on the contrary, but I prefer to discuss
this in a separate thread.)

> 
> I'd encourage the RT to push even more for an 'unstable' suite dedicated 
> to the release process.

That's about changing the freeze policy, not about respecting the current
freeze policy. (I'm not rejecting this, on the contrary, but I prefer to
discuss this in a separate thread.)

> Development can perfectly "continue" in 
> experimental.

That is suggested in the freeze policy if the uploads in unstable would be
disruptive.

So, Didier, I think that you bring up a few interesting additional aspects
certainly worth some debate (preferably in separate threads per aspect being
discussed), and that about respecting the freeze policy (the topic of this
thread) we should in my opinion all stick to the text of the freeze policy and
comply to it during the entire freeze.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204100818.ga...@master.debian.org

Re: Bug#772001: ITP: ruby-rails-assets-perfect-scrollbar -- Tiny but perfect jQuery scrollbar plugin

[Andrei POPESCU]

Control: reassign -1 wnpp

On Jo, 04 dec 14, 15:16:30, Syam G Krishnan wrote:
> package: perfect-scrollbar
> Severity: wishlist
> Owner: 'syam' 
> 
> *Package Name : perfect-scrollbar
>  Version : 2.1.2
>  Upstream Author : Hyunje Alex Jun (Author name/s of the Gem).
> *URL :  https://github.com/noraesae/perfect-scrollbar (Link to the git
> repo of the Gem)
> *License : MIT
> *Description :  Tiny but perfect jQuery scrollbar plugin
> 
> I am packaging perfect-scrollbar as it is a dependency of rails-assets
> (#691181)  which is a dependency of diaspora (#597093)

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#772011: ITP: kafkacat -- generic producer and consumer for Apache Kafka

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: kafkacat
  Version : 1.0.0
  Upstream Author : Magnus Edenhill 
* URL : https://github.com/edenhill/kafkacat
* License : BSD
  Programming Lang: C
  Description : generic producer and consumer for Apache Kafka

kafkacat is a generic non-JVM producer and consumer for Apache Kafka
0.8, think of it as a netcat for Kafka.

In producer mode kafkacat reads messages from stdin, delimited with a
configurable delimeter and produces them to the provided Kafka
cluster, topic and partition. In consumer mode kafkacat reads messages
from a topic and partition and prints them to stdout using the
configured message delimiter.

kafkacat also features a Metadata list mode to display the current
state of the Kafka cluster and its topics and partitions.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUgD4eAAoJEJWkL+g1NSX5eA8P/i9LyGFu9YcztDLP3OGwF7wC
wtEZdSEtbiCusukoSsfbcqR0fMqD5WHt7fe6kDYcxMUkP5nr2RVfuAVf8fLXLxPx
ADzvG7T0C5b8/TTFaIJLjj6HY6D5bHVm+9g+6sF04mWwfIc1Ypfd/utd4fiPpwJP
oT779du25cEqiIkcTBHVIm2opiAJ4t7RGh4DFHW43JV47V+RjbihEUOVfdgoM+LM
twDJBK3sxHIq6i9cMazP03BYVvuvUvGJi3iyX5BZTcI/uODmic7A/Mmwppa5eGF0
CO+D7tReKlIEkI0IlxLwNSr+ltqHrY1CM6MtfMv4mbJTHE4LcnmS9tI40EEHVdOm
v5zgWkB0Qy7HPmAsvYQWuyfmB3Bkotzz6UPudpT7SgE7HkbzibpMrcamE0WdfcHm
dY5LhgveN+IrE+EV8cKdWNKMSXiX5AXF1zfq0civh2j7qHDqiUQ5b00kpQqjwTCY
z3l7A3IYwzetChOvKzL+TQOVvGKYu/GsYwWoH6GfAmt0e5OexYL7Ygvrk25YyRG4
8LTybcRSsOYeWUdr19M0WGWXyPeC9c3sEOSlsk+6l32K2s0MOo+xo9Jhg5RQ1kIo
q3mXLaJ489zSHBsV++cAP2bnFg4H4hlYFTPDa1xuNWt1wPZ0fhZ3l+dD1wf+742l
nGNXR6pu55cSy1P2dfvK
=Zd5p
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141204105738.31931.79125.report...@zoro.exoscale.ch

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote:
> Hello,

> In summary:
> a) Upgrades should _not_ change init: whatever is installed should be
> kept.
> b) New installs should get systemd-sysv as default init with a debconf
> message about alternative init systems.
> 
> More detailed:
> 1) Fix debootstrap bugs
> 2) Add a (non-aborting) debconf message referring to release-notes on
> how to install sysvinit-core when installing from scratch.
> 3) Add information in release-notes on how to:
> - Upgrade from stable/testing/sid to jessie to avoid getting
> systemd-sysv installed (this should not strictly be needed if the ctte
> chooses to decide that upgrades will _not_ switch init)
> - Install sysvinit-core after installation and reboot after getting
> systemd-sysv as default.
> 
> 3.1) I'll file a bug against release-notes as written above.

Hopefully the ctte will make a decision on init system for upgrades to
Jessie today!

FYI: Bugs for release-notes on upgrades, #771825, and installation-guide
(and perhaps debian wiki) on new installs (pending), are in the pipe!



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417692256.3453.60.ca...@g3620.my.own.domain

Bug#772019: ITP: python-proliantutils -- client lib interfacing various devices in HP Proliant Servers

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-proliantutils
  Version : 0.1.1
  Upstream Author : Nisha Agarwal 
* URL : https://github.com/hpproliant/proliantutils
* License : Apache-2.0
  Programming Lang: Python
  Description : client lib interfacing various devices in HP Proliant 
Servers

 Proliant Management Tools provides python libraries for interfacing and
 managing various devices(like iLO) present in HP Proliant Servers. Currently,
 this module offers a library to interface to iLO4 using RIBCL.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141204123901.26710.35941.report...@buzig.gplhost.com

Re: delete my resume in your web site

[Nikos Andrikos]

On another note, is it just me or the links in the following line of the
bug report are wrong?

*Bug reassigned from package 'listarchives
'
to 'lists.debian.org
'.*
Request
was from Andrei POPESCU  to
cont...@bugs.debian.org


--
=Do-
N.AND

2014-12-03 16:12 GMT+01:00 Amaya :

> Jenny zhou wrote:
> >  I requested many time. but my resume is still on your web site.
>
> This has been reported as a bug (as per ml policy)
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769807
>
> --
>  .''`.The world breaks everyone, and afterward, some are
> : :' :strong at the broken places.- Ernest Hemingway
> `. `'
>   `-Proudly running Debian GNU/Linux
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20141203151211.GA21126@aenima
>
>

Bug#772027: ITP: blogliterately -- Tool for posting Haskelly articles to blogs

[Dmitry Bogatov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Bogatov 

* Package name: blogliterately
  Version : 0.7.1.7
  Upstream Author : Brent Yorgey 
* URL : http://byorgey.wordpress.com/blogliterately/
* License : GPL3+
  Programming Lang: Haskell
  Description : Tool for posting Haskelly articles to blogs

Upstream description:

This package provides development internals of BlogLiterately
tool, allowing you write blog posts in Markdown format, then
use it to do syntax highlighting, format ghci sessions, and
upload to any blog supporting the metaWeblog API (such as
Wordpress)

This package is made avaliliable to make customization
possible, in particular, to create your own executable which
adds extra custom transformations.

In short: it is awesome utility(imho), that allows to publish articles
from console, without browser and javascript at all. It also can
highlight code and interact with ghci. As far, as I know, it is the
only of its kind, I use and plan to maintain it. I will need a sponsor
to upload it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141204134817.24706.327.report...@self.kaction.name

Announcing a Debian Hamradio Blend

[iw0fzw]

Ian R Leamonth,

In Debian GNU/linux they NEVER discussed to port other packages, infact in
different situations i discuss this on debian-hamradio and on #fsf where
they said that there was not any necessity to port the packages, and that
is left to the user the freedom, to take the packages in source code, from
third parties, to build it, and to use it.

I said: "if a user don't find a package in the mirrors, he think that does
not exist", but they prefeer to ignore what i said, belittling what i said
to them.

A day i decided to power on my Kenwood TM-255E, i was on 145.750 -600Khz,
and while i was taking my shower, i listened a radioamateur, which discuss
with another one, about the fact that on GNU/linux are not available
enough packages for hamradio.

I finished to take my shower, and again wet, i asked to break the
communication, i said my callsign: iw0fzw, my name: paolo and my locator:
jn61fu, and spoke, about the fact that there are 330 packages to port, and
not again ported on the mirrors, now, Debian Community, all of a sudden
wake up, and decides to port the packages.

So is very easy, and don't mention who said them to do this.

Awaiting for your reply,

73 paolo iw0fzw

p.s: is very easy to ignore, what say the other people, so that they can
take all the credits.

to show that they are saying the false, here i upload as attachment the
file hamradio

i asked too support to my friend Danilo to package all the sowfatware
availbale only as source code on third parties.

I should now take me for a ride by those of Debian?

how you would feel to be taken for a ride by some people?


hamradio
Description: Binary data

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 29.11.2014 20:43, Svante Signell wrote:

> The best for kFreeBSD and Hurd would be to abandoning the Debian ship.
> It is sinking :( (just let the devuan people get things in order first)

Well, I'll also put my projecsts on getting rid of polkit into that
direction. Why ? Because I've got the impression that these guys
still value traditional unix concepts, like using the filesystem
for simple hierarchical data structures and access control, tiny
and easily compositable servers and tools, etc.


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5480782f.3050...@gr13.net

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 29.11.2014 20:45, Ivan Shmakov wrote:

>   As for Systemd being the default (on Debian GNU/Linux,
>   specifically), – I guess I shouldn’t bother.  GNOME is also the
>   default, but I cannot readily recall ever having it running on
>   my Debian installs.
> 

By the way: didn't GNOME originally have the intention of being
crossplaform, not Linux-only ?


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5480793e.3000...@gr13.net

Re: curl and certificate verification in jessie

[Ian Jackson]

Firstly, I should say that I agree with Peter and Tollef's objectives.

I'm not an expert on TLS but I was under the impression that this
behaviour - requiring that TLS authentication be done by a nontrivial
certificate chain - was specified by the standards (presumably X.509
rather than TLS).  I could be wrong.

Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> No, it doesn't necessarily.  As dkg points out, I can no longer say
> «this service should have this particular cert».  This makes us
> vulnerable to compromises of the CA that provides the cert for a given
> service and a lowering of the overall security in this particular setup.

There is a straightforward workaround for this.

Each time you generate an EE key which you intend to use this way,
also create an ad-hoc single-shot CA.  Generate one EE certificate
using the CA, on the EE public key, and then throw the CA private key
away (or keep it alongside the EE private key).  In clients, configure
the ad-hoc CA public key instead of the EE public key.

This has identical security and key management properties to trying to
configure the EE public key directly in clients.  (Aside from the
security risks of the extra complication.)  In a conversation about
the ftp-master data api service I provided some scripts which are
intended to do all this.

This is of course all very tedious and it would be nice to fix the TLS
libraries.  But if (as I suspect) the desired configuration is
(absurdly) forbidden by the standards, we might have to use this
workaround.

Thanks,
Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21632.32933.499745.697...@chiark.greenend.org.uk

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 28.11.2014 19:09, Christoph Anton Mitterer wrote:

> For many things, CGI is actually the only way to run them securely,
> since it's the only way to run foreign processes in a container
> environment (chroots, etc.) or with user privilege separation.

Not entirely true. About a decade ago, I've wrote muxmpm, which ran
individual sites under their own uid/gid, chroot, etc. That made things
like cgixec, php's safe_mode etc practically obsolete.

It was even shipped by several large distros, eg. suse (the orignal
one, not novell).


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54807f48.9060...@gr13.net

Re: Announcing a Debian Hamradio Blend

[Iain R. Learmonth]

Hi Paolo,

(Removing debian-blends@lists.d.o from CC as this topic is not relevant there.)

On Thu, Dec 04, 2014 at 02:40:06PM -, iw0...@riseup.net wrote:
> here i upload as attachment the file hamradio

Thanks for this list of software. Looking through the list I can see a lot
of good candidates for inclusion in Debian, and will look at filing RFP bugs
for these where it seems the software is currently maintained and where the
software looks to be useful. Once I have RFP bugs filed, I will also add
these packages to the relevant tasks in the Hamradio Blend, creating new
tasks if necessary.

Please do be patient though, as myself and the Hamradio Maintainers team
volunteer our spare time to work on Debian and it is sometimes the case that
there is not enough spare time to get everything done we would like.

If there are any packages in particular you would like to see packaged,
please let me know, and I can take a look at them specifically. I imagine
it's going to take a while to go through the entire list you've provided.

Thanks,
Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: 2M0STB  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgp4GBEa8jiiq.pgp
Description: PGP signature

Re: DE features dependent on Systemd

[Marvin Renich]

* Matthias Urlichs  [141130 09:22]:
> But on a multi-user system, we can't depend on the first user being any
> sort of special owner; it might just as well be the person whose desk
> the machine is hidden under

I strongly disagree with this.  The person performing the installation
clearly has root privileges while the installation is being performed,
and is much more likely to be at least one of the people responsible for
maintaining the system.  While not a universal truth, there is a high
probability that this person will have additional privileges beyond a
normal user, either by the first user being added to extra groups, by
the person doing the installation having root privileges (by knowing the
root password or through sudo), or both.

As for the fallacy that adding the first user to additional groups is a
privacy or security issue, if we can agree that there is at least one
administrator with root privileges, and the first user added by the
installer likely belongs to such a person, what good does it do to not
add the first user to the audio group?  With root privileges, the admin
can do all of the things mentioned in this thread to invade other users'
privacy.  Trying to give a false sense of security by saying "we don't
give the first user special privileges, so you don't have to worry about
being spied on remotely" is a complete lie.  If you don't trust the
administrators of your machine, then assume they are spying on you;
there is no other reasonable assumption, and refusing to add the first
user to special groups does not change that.

The only case where not adding the first user to special groups would
make a difference is when the person doing the installation for a
machine shared by multiple users asks the installer to add the first
user, but assigns that first user to one of the non-administrators of
the machine.  I think this is extremely rare in practice, in both
business and home settings.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204152736.gf3...@basil.wdw

Re: Technical committee acting in gross violation of the Debian constitution

[Matthias Urlichs]

Hi,

Christoph Anton Mitterer:
> For many things, CGI is actually the only way to run them securely,
> since it's the only way to run foreign processes in a container
> environment (chroots, etc.) or with user privilege separation.

?

If you can run a CGI inside a chroot/container/whatever, you can run a
small web server on a local port / Unix socket, and reverse-proxy it,
just as easily.

FastCGI is just a slightly more fancy way of doing this.

> The poor man alternatives like mod-php5 are nothing which a security
> conscious admin would ever use.
> 
Definitely.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204160325.gs6...@smurf.noris.de

Re: curl and certificate verification in jessie

[Tollef Fog Heen]

]] Ian Jackson 

> Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> > No, it doesn't necessarily.  As dkg points out, I can no longer say
> > «this service should have this particular cert».  This makes us
> > vulnerable to compromises of the CA that provides the cert for a given
> > service and a lowering of the overall security in this particular setup.
> 
> There is a straightforward workaround for this.
> 
> Each time you generate an EE key which you intend to use this way,
> also create an ad-hoc single-shot CA.  Generate one EE certificate
> using the CA, on the EE public key, and then throw the CA private key
> away (or keep it alongside the EE private key).  In clients, configure
> the ad-hoc CA public key instead of the EE public key.

Given we want those certificates to be usable by people using normal web
browsers too, this will lead to lots of popups about untrusted CAs,
unless we get our certificate provider to sign those CA certs for us.  I
don't think they're willing to do that.

> This is of course all very tedious and it would be nice to fix the TLS
> libraries.  But if (as I suspect) the desired configuration is
> (absurdly) forbidden by the standards, we might have to use this
> workaround.

This is free software.  We can fix the software to DTRT if we need to.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2k327s89t@rahvafeir.err.no

Re: curl and certificate verification in jessie

[Ian Jackson]

Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> Ian Jackson:
> > Each time you generate an EE key which you intend to use this way,
> > also create an ad-hoc single-shot CA.  Generate one EE certificate
> > using the CA, on the EE public key, and then throw the CA private key
> > away (or keep it alongside the EE private key).  In clients, configure
> > the ad-hoc CA public key instead of the EE public key.
> 
> Given we want those certificates to be usable by people using normal web
> browsers too, this will lead to lots of popups about untrusted CAs,
> unless we get our certificate provider to sign those CA certs for us.  I
> don't think they're willing to do that.

Oh, I see.  I hadn't understood you were trying to do that too.

> > This is of course all very tedious and it would be nice to fix the TLS
> > libraries.  But if (as I suspect) the desired configuration is
> > (absurdly) forbidden by the standards, we might have to use this
> > workaround.
> 
> This is free software.  We can fix the software to DTRT if we need to.

That's true, but we might not want to carry an intrusive
security-relevant patch.  I asked around on a local irc channel and am
none the wiser about the standards question.

I haven't done any code archaeology in gnutls28.  I think that's the
next place to look, since no-one seems to have any better information :-/.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21632.36655.971578.60...@chiark.greenend.org.uk

Re: curl and certificate verification in jessie

[Daniel Kahn Gillmor]

On 12/04/2014 10:41 AM, Ian Jackson wrote:

> I'm not an expert on TLS but I was under the impression that this
> behaviour - requiring that TLS authentication be done by a nontrivial
> certificate chain - was specified by the standards (presumably X.509
> rather than TLS).  I could be wrong.

FWIW, i'm not convinced that there are any standards that say that a TLS
endpoint MUST validate its peer by means of a hierarchical CA.

even if there were, i suspect most implementations would provide a
mechanism to ignore that MUST.

The issue here is that GnuTLS upstream apparently wants to distinguish
between the "here's a CA" case and the "here's a certificate that's
valid for this host" case. [0]

The main argument seems to be that if you decide you are willing to rely
on a CA, that means you're accepting anything they give you.

But if you say "i believe this cert is ok for a peer" with no other
information, you're actually accepting the cert for *any* of the
subjectAltNames it has.

This makes it far too easy for me to visit https://some.random.example
and "accept" their cert, but not notice that the cert also has
alioth.debian.org as a subjectAltName.  now the administrator of
some.random.example can impersonate alioth to me.

So, the idea is that when you "accept" an EE cert, you need to do it
with an explicit associate to a specific peer's name, not just the cert
itself.  newer versions of GnuTLS provide this facility, but it's not
the traditional (and potentially dangerous) "here's a package of certs
i'm OK with" interface that it was before.  And of course that interface
isn't used by curl yet.

Unfortunately, this is quite a subtle API change, and it's not clear how
to do it safely or sanely.

I'm currently unsure what the right thing to do is about this situation.

--dkg

[0] http://lists.gnupg.org/pipermail/gnutls-devel/2014-December/007274.html



signature.asc
Description: OpenPGP digital signature

Re: delete my resume in your web site

[Amaya]

Nikos Andrikos wrote:
> On another note, is it just me or the links in the following line of the
> bug report are wrong?
> 
> *Bug reassigned from package 'listarchives
> '
> to 'lists.debian.org
> '.*
> Request
> was from Andrei POPESCU  to
> cont...@bugs.debian.org

Yes, the footer generates two 404 links to both the 'listarchives' and
'lists.debian.org' bts pages. 

-- 
 .''`.The world breaks everyone, and afterward, some are
: :' :strong at the broken places.- Ernest Hemingway
`. `'   
  `-Proudly running Debian GNU/Linux


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204165346.GB21126@aenima

Bug#772047: RFH: pgpool2 -- connection pool server and replication proxy for PostgreSQL

[Christoph Berg]

Package: wnpp
Severity: normal

I request assistance with maintaining the pgpool2 package in the
PostgreSQL team. I'm not using the package myself - someone with more
experience in actually running pgpool2 would be welcome to take care
of getting the more advanced features (e.g. memcached support) into
shape.

The package description is:
 pgpool-II is a middleware that works between PostgreSQL servers and a
 PostgreSQL database client. It provides the following features:
 .
  * Connection Pooling
  * Replication
  * Load Balance
  * Limiting Exceeding Connections
  * Parallel Query
 .
 pgpool-II talks PostgreSQL's backend and frontend protocol, and relays a
 connection between them. Therefore, a database application (frontend) thinks
 that pgpool-II is the actual PostgreSQL server, and the server (backend) sees
 pgpool-II as one of its clients. Because pgpool-II is transparent to both the
 server and the client, an existing database application can be used with
 pgpool-II almost without a change to its sources.
 .
 This is version 3 of pgpool-II, the second generation of pgpool.

If you are interested, please let me or the PostgreSQL packages
mailing list know.

Thanks,
Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204170408.ga23...@msg.df7cb.de

Re: delete my resume in your web site

[Don Armstrong]

On Thu, 04 Dec 2014, Nikos Andrikos wrote:
> On another note, is it just me or the links in the following line of
> the bug report are wrong?

Yeah, this is a bug which I've actually fixed in my code branch, and
will need to update shortly. [Basically, the precise html escape used
changed, and the code that linkified was too brittle.]


-- 
Don Armstrong  http://www.donarmstrong.com

[I]t's true that some of the most terrible things in the world are
done by people who think, genuinely think, that they're doing it for
the best, especially if there is some god involved.
 -- Terry Pratchett _Snuff_ p185


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204182637.gk31...@rzlab.ucr.edu

Re: curl and certificate verification in jessie

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: curl and certificate verification in jessie"):
> So, the idea is that when you "accept" an EE cert, you need to do it
> with an explicit associate to a specific peer's name, not just the cert
> itself.  newer versions of GnuTLS provide this facility, but it's not
> the traditional (and potentially dangerous) "here's a package of certs
> i'm OK with" interface that it was before.  And of course that interface
> isn't used by curl yet.

How about the following change to GnuTLS: if _all_ of the supplied
certificates are EE certificates (eg, have the critical CA constraint
set to false), we disable this check ?

In that situation it is clear that the caller is not trying to use the
X.509 CA infrastructure at all and has been `abusing' the CA interface
to provide the expected public keys directly.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21632.44185.191543.583...@chiark.greenend.org.uk

Re: curl and certificate verification in jessie

[Daniel Kahn Gillmor]

On 12/04/2014 01:48 PM, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: curl and certificate verification in 
> jessie"):
>> So, the idea is that when you "accept" an EE cert, you need to do it
>> with an explicit associate to a specific peer's name, not just the cert
>> itself.  newer versions of GnuTLS provide this facility, but it's not
>> the traditional (and potentially dangerous) "here's a package of certs
>> i'm OK with" interface that it was before.  And of course that interface
>> isn't used by curl yet.
> 
> How about the following change to GnuTLS: if _all_ of the supplied
> certificates are EE certificates (eg, have the critical CA constraint
> set to false), we disable this check ?
> 
> In that situation it is clear that the caller is not trying to use the
> X.509 CA infrastructure at all and has been `abusing' the CA interface
> to provide the expected public keys directly.

thanks, that's a very interesting idea.  I'll bring it up with upstream.

It seems to narrowly solve the case in question, but possibly at the
risk of making the semantics of the API even more confusing than it
already is.

--kg



signature.asc
Description: OpenPGP digital signature

Re: curl and certificate verification in jessie

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: curl and certificate verification in jessie"):
> It seems to narrowly solve the case in question, but possibly at the
> risk of making the semantics of the API even more confusing than it
> already is.

If they didn't want the API to be full of confusing
backward-compatibility special cases, they shouldn't make
backwards-incompatible changes :-).

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21632.45246.979715.436...@chiark.greenend.org.uk

Re: curl and certificate verification in jessie

[Ian Jackson]

Ian Jackson writes ("Re: curl and certificate verification in jessie"):
> Daniel Kahn Gillmor writes ("Re: curl and certificate verification in 
> jessie"):
> > It seems to narrowly solve the case in question, but possibly at the
> > risk of making the semantics of the API even more confusing than it
> > already is.
> 
> If they didn't want the API to be full of confusing
> backward-compatibility special cases, they shouldn't make
> backwards-incompatible changes :-).

More constructively: I think we should consider carrying such a patch
in Debian for jessie even if upstream don't want it in their API
permanently.

In stretch we can add new options to curl to make it use the new API.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21632.45452.999624.782...@chiark.greenend.org.uk

Re: successful upgrade to jessie - thanks!

[Troy Benjegerdes]

On Thu, Nov 27, 2014 at 03:06:17PM +0100, David Kalnischkies wrote:
> Hi Tomas,
> 
> Great you like it! Many people are busy working on smoothing the edges
> uncovered by all the inflowing bugreports, so the occasional "thanks!"
> is a nice boost to troop morale. :)

I will second the thank you.. I got through 2 machines with the jessie
upgrade with less trouble than I had with removing bash when we had 
exploits a few months ago.

> 
> On Thu, Nov 27, 2014 at 02:22:14PM +0100, Tomas Pospisek wrote:
> > Allthough apt-get dist-upgrade broke half way through due to
> > unresolvable package dependencies, I was able to finish the upgrade via
> > aptitude's ncurses interface.
> 

Something, somewhere broke hibernation/sleep on my macbook air, and the 
synaptics touchpad, and one of these days I'll figure it out.

Now if we could just redirect all this negative energy into removing 
dependencies on the 'bizarre' syntax that bash has in init scripts, and
I could do 'apt-get remove bash', a great thing will have happened ;)

So, keep up the good work, and if you must talk about pain and doom and
gloom, talk about the doom and gloom that comes if you remove bash :P


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204195918.gh29...@nl.grid.coop

Re: curl and certificate verification in jessie

[Tollef Fog Heen]

]] Daniel Kahn Gillmor 

> On 12/04/2014 10:41 AM, Ian Jackson wrote:
> 
> > I'm not an expert on TLS but I was under the impression that this
> > behaviour - requiring that TLS authentication be done by a nontrivial
> > certificate chain - was specified by the standards (presumably X.509
> > rather than TLS).  I could be wrong.
> 
> FWIW, i'm not convinced that there are any standards that say that a TLS
> endpoint MUST validate its peer by means of a hierarchical CA.
> 
> even if there were, i suspect most implementations would provide a
> mechanism to ignore that MUST.
> 
> The issue here is that GnuTLS upstream apparently wants to distinguish
> between the "here's a CA" case and the "here's a certificate that's
> valid for this host" case. [0]
> 
> The main argument seems to be that if you decide you are willing to rely
> on a CA, that means you're accepting anything they give you.
> 
> But if you say "i believe this cert is ok for a peer" with no other
> information, you're actually accepting the cert for *any* of the
> subjectAltNames it has.
> 
> This makes it far too easy for me to visit https://some.random.example
> and "accept" their cert, but not notice that the cert also has
> alioth.debian.org as a subjectAltName.  now the administrator of
> some.random.example can impersonate alioth to me.

This reasoning makes sense, for applications which do store certs.

> So, the idea is that when you "accept" an EE cert, you need to do it
> with an explicit associate to a specific peer's name, not just the cert
> itself.  newer versions of GnuTLS provide this facility, but it's not
> the traditional (and potentially dangerous) "here's a package of certs
> i'm OK with" interface that it was before.  And of course that interface
> isn't used by curl yet.
> 
> Unfortunately, this is quite a subtle API change, and it's not clear how
> to do it safely or sanely.

For curl, it sounds like a simple curl_set_option(CURL_SSL_EE_CERT,…)
call or similar would make sense and then expose that to the command
line too.  If I do curl --tls-ee-certs=somefile.crt https://www…, I
probably don't care if somefile.crt has a subjectAltName for alioth or
google.

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


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

Re: successful upgrade to jessie - thanks!

[Troy Benjegerdes]

On Thu, Nov 27, 2014 at 03:06:17PM +0100, David Kalnischkies wrote:
> Hi Tomas,
> 
> Great you like it! Many people are busy working on smoothing the edges
> uncovered by all the inflowing bugreports, so the occasional "thanks!"
> is a nice boost to troop morale. :)

Btw, debian is the only complex software system I know of in the history
of the universe that can point to 'successful' upgrade of the size and
complexity that is going on now.

I should qualify this as 'complex systems that can be used to re-create
themselves with minimal external dependencies'. I am sure some mainframes
have the level of upgradeability debian has, but you can't design a new
mainframe CPU on a mainframe, and I can design a CPU (slowly) with tools
in the debian archive.

-- 

Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204200440.gi29...@nl.grid.coop

Re: Technical committee acting in gross violation of the Debian constitution

[Marco d'Itri]

On Dec 04, Matthias Urlichs  wrote:

> If you can run a CGI inside a chroot/container/whatever, you can run a
> small web server on a local port / Unix socket, and reverse-proxy it,
> just as easily.
While using many more times the resources. You obviously have no idea of 
the challenges of providing secure web hosting for non-trivial 
quantities of web sites.

> FastCGI is just a slightly more fancy way of doing this.
FastCGI is another thing that almost nobody can afford when hosting 
a significant number of web sites.

-- 
ciao,
Marco


pgpIRIYDkhZ2t.pgp
Description: PGP signature

Re: Technical committee acting in gross violation of the Debian constitution

[Matthias Urlichs]

Hi,

Marco d'Itri:
> On Dec 04, Matthias Urlichs  wrote:
> 
> > If you can run a CGI inside a chroot/container/whatever, you can run a
> > small web server on a local port / Unix socket, and reverse-proxy it,
> > just as easily.
> While using many more times the resources.

Which "many more" are you talking about? Setting up a chroot and starting
an external program has the same cost. Thus, a CGI script is more expensive
than a FastCGI process or a small web app (Python Flask or whatever) as
soon as the second request for a resource it serves arrives.

> You obviously have no idea of the challenges of providing secure web
> hosting for non-trivial quantities of web sites.

You obviously assume that the users' app servers need to actually
run before they're able to serve requests.

This assumption is incorrect.

I start the app server and its container via socket activation. (In most
cases, unfortunately, this is a simple php5-fpm server.) I then stop it
after a few seconds of inactivity (or with an LRU list, based on how much
server memory is left). Problem solved.

… at least in principle; socket activation still isn't exactly common,
so this solution still requires a couple of hacks to work, and I really
should submit some patches. :-/  But it works.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141204205543.gt6...@smurf.noris.de

Re: Please respect Freeze Policy

[Niels Thykier]

On 2014-12-04 08:46, Bart Martens wrote:
> On Wed, Dec 03, 2014 at 10:42:54AM +0100, Didier 'OdyX' Raboud wrote:
>> Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit :
>>> Would it be OK to abuse experimental for new upstreams during
>>> freeze?
>>
>> during freezes, where unstable should only have 
>> changes targeted at testing (and therefore, currently, at jessie).
> 
> I don't read that in the freeze policy. Do you?
> https://release.debian.org/jessie/freeze_policy.html
> 

The release team do not have jurisdiction over unstable.  Accordingly,
we cannot impose a rule on what you can (or cannot) upload to unstable.

> The key term about this in the freeze policy is "disruptive". It's up to the
> package maintainer to judge whether a package update should go to unstable or
> experimental depending on whether the package update could be disruptive in
> unstable.
> 
>> [...]
> 
> Regards,
> 
> Bart Martens
> 
> 


Unfortunately, it is equally disruptive when people (despite best
efforts) misjudge the consequences of their upload.  In such a case, you
would be depriving your fellow co-Debianites from the opportunity of
getting some patches into testing.
  /This/ is why we recommend that people upload new upstream releases
(etc.) to experimental.

~Niels

Pro-tip: If your upload bumps shlib or symbols, it will definitely
become a liability for reverse dependencies.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5480cd56.6090...@thykier.net

Re: Technical committee acting in gross violation of the Debian constitution

[Christoph Anton Mitterer]

On Thu, 2014-12-04 at 17:03 +0100, Matthias Urlichs wrote: 
> If you can run a CGI inside a chroot/container/whatever, you can run a
> small web server on a local port / Unix socket, and reverse-proxy it,
> just as easily.
Well that's probably roughly the same, although I'd still feel better if
webserver and actual services/programs run with different UIDs, which
seems especially important when one also does DB accesses (i.e. access
control based on the UID).


> FastCGI is just a slightly more fancy way of doing this.
Sure... I didn't meant to exclude FastCGI, but last time I've checked it
didn't allow to run different PHP (talking about the PHP fastcgi version
now) programs to run with different UIDs (all run with that of FPM)...
but maybe I just didn't check carefully enough.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Technical committee acting in gross violation of the Debian constitution

[Christoph Anton Mitterer]

On Thu, 2014-12-04 at 21:14 +0100, Marco d'Itri wrote: 
> While using many more times the resources. You obviously have no idea of 
> the challenges of providing secure web hosting for non-trivial 
> quantities of web sites.
So what do you want to imply would be secure?

Apart from that, when you speak of "non-trivial" quantities - I'd
probably say that running gazillion websites from different entities on
one host is generally a really bad idea.

So I don't think your argument really counts that much (assumed I've
understood it correctly ;) ).


> > FastCGI is just a slightly more fancy way of doing this.
> FastCGI is another thing that almost nobody can afford when hosting 
> a significant number of web sites.
Why not?

When I've investigated in mod-php vs. cgi vs. fcgi, the fcgi turned out
to have roughly the same performance as mod-php (plain cgi of course
much worse).
In addition: mod-php can only be used with mpm-prefork, as it's not
thread safe.

So I wouldn't see anything (except XYZ should run insecurely
out-of-the-box) which makes mod-php better in any use case than the
alternatives.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Technical committee acting in gross violation of the Debian constitution

[Marco d'Itri]

On Dec 04, Christoph Anton Mitterer  wrote:

> > While using many more times the resources. You obviously have no idea of 
> > the challenges of providing secure web hosting for non-trivial 
> > quantities of web sites.
> So what do you want to imply would be secure?
The point is not just "secure", but "secure and scalable".
And sadly the only good solution that fits this criteria is php-cgi with
some kind of uid-changing wrapper.

> Apart from that, when you speak of "non-trivial" quantities - I'd
> probably say that running gazillion websites from different entities on
> one host is generally a really bad idea.
Web hosting is a complex business.

> > FastCGI is another thing that almost nobody can afford when hosting 
> > a significant number of web sites.
> Why not?
Because RAM is expensive and you cannot keep tens or even thousands of 
fastcgi processes around waiting for a request.

> So I wouldn't see anything (except XYZ should run insecurely
> out-of-the-box) which makes mod-php better in any use case than the
> alternatives.
This is correct.

-- 
ciao,
Marco


pgp8sy1ENn0Io.pgp
Description: PGP signature

Re: Technical committee acting in gross violation of the Debian constitution

[Marc Haber]

On Thu, 04 Dec 2014 22:23:15 +0100, Christoph Anton Mitterer
 wrote:
>Apart from that, when you speak of "non-trivial" quantities - I'd
>probably say that running gazillion websites from different entities on
>one host is generally a really bad idea.

Gazillions of websites are served from such setups. Yes, using Debian.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xwfza-0001yi...@swivel.zugschlus.de

Re: Technical committee acting in gross violation of the Debian constitution

[Russ Allbery]

Christoph Anton Mitterer  writes:
> On Thu, 2014-12-04 at 21:14 +0100, Marco d'Itri wrote: 

>> FastCGI is another thing that almost nobody can afford when hosting a
>> significant number of web sites.

> Why not?

> When I've investigated in mod-php vs. cgi vs. fcgi, the fcgi turned out
> to have roughly the same performance as mod-php (plain cgi of course
> much worse).

FastCGI, at least the normal way I've seen it deployed, sets up a running
daemon for each script that's running via FastCGI.  (You can spawn those
dynamically to some extent, but that's fairly limited, and then you're
mostly reproducing a standard CGI environment with extra complexity.)

If your web site hosting has unbounded numbers of untrusted scripts that
it may be running (I've had to solve this problem for unique script counts
over one million), that FastCGI environment is rather... challenging to
set up.

In the long run, that sort of sandbox environment is dying for other
reasons, and people are gravitating towards application platforms like
Drupal that pose other, different maintenance challenges.  But FastCGI is
not a replacement for standard CGI if you actually fully used the
capabilities of standard CGI (merits of allowing that aside -- it's hard
to turn insecure things off when tens of thousands of people have written
lots and lots of web sites assuming that behavior).

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tofx8v8@hope.eyrie.org

Work-needing packages report for Dec 5, 2014

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 655 (new: 10)
Total number of packages offered up for adoption: 147 (new: 0)
Total number of packages requested help for: 57 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   canlock (#771878), orphaned yesterday
 Description: library for creating and verifying Usenet cancel locks
 Reverse Depends: libcanlock2-dev slrn tin
 Installations reported by Popcon: 1395

   gmp-ecm (#771880), orphaned yesterday
 Description: Factor integers using the Elliptic Curve Method
 Reverse Depends: gmp-ecm libecm-dev
 Installations reported by Popcon: 108

   mpclib (#771881), orphaned yesterday
 Description: multiple precision complex floating-point library
 Installations reported by Popcon: 97899

   mpclib3 (#771882), orphaned yesterday
 Description: multiple precision complex floating-point library
 Reverse Depends: cpp-4.6 cpp-4.7 cpp-4.8 cpp-4.9
   cpp-4.9-aarch64-linux-gnu cpp-4.9-arm-linux-gnueabi
   cpp-4.9-arm-linux-gnueabihf cpp-4.9-mips-linux-gnu
   cpp-4.9-mipsel-linux-gnu cpp-4.9-powerpc-linux-gnu (76 more omitted)
 Installations reported by Popcon: 27572

   mpfi (#771883), orphaned yesterday
 Description: multiple precision floating-point interval computation
   library
 Reverse Depends: gap-float libmpfi-dev
 Installations reported by Popcon: 231

   mpfr4 (#771884), orphaned yesterday
 Description: multiple precision floating-point computation
 Reverse Depends: aranym cpp-4.4 cpp-4.6 cpp-4.7 cpp-4.8 cpp-4.9
   cpp-4.9-aarch64-linux-gnu cpp-4.9-arm-linux-gnueabi
   cpp-4.9-arm-linux-gnueabihf cpp-4.9-mips-linux-gnu (117 more
   omitted)
 Installations reported by Popcon: 142203

   p3scan (#771487), orphaned 4 days ago
 Description: transparent POP3-proxy with virus- and spam-scanning
 Installations reported by Popcon: 53

   pegasus-wms (#771488), orphaned 4 days ago
 Description: Scientific workflow management system for HTCondor
 Installations reported by Popcon: 7

   renattach (#771489), orphaned 4 days ago
 Description: Rename attachments on the fly
 Installations reported by Popcon: 32

   xstow (#771490), orphaned 4 days ago
 Description: Extended replacement of GNU Stow
 Installations reported by Popcon: 96

645 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 147 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

[NEW] pgpool2 (#772047), requested today
 Description: connection pool server and replication proxy for
   PostgreSQL
 Reverse Depends: libpgpool-dev pgpool2 postgresql-9.4-pgpool2
 Installations reported by Popcon: 159

   apt-xapian-index (#567955), requested 1767 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache goplay packagesearch
 Installations reported by Popcon: 76444

   athcool (#278442), requested 3691 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 40

   awstats (#755797), requested 134 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4148

   balsa (#642906), requested 1166 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 740

   cardstories (#624100), requested 1319 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 9

   chromium-browser (#583826), requested 1649 days ago
 Description: Chromium browser
 Reverse Depends: chromedriver chromium-dbg chromium-l10n
   design-desktop-web mozplugger
 Installations reported by Popcon: 25756

   cups (#532097), requested 2007 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cinnamon-settings-daemon
   cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client
   cups-core-drivers (64 more omitted)
 Installations reported by Popcon: 143406

   debtags (#567954), requested 1767 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2311

   developers-re

gnome depending on apache [WAS: Technical committee acting in gross violation of the Debian constitution]

[Enrico Weigelt, metux IT consult]

On 02.12.2014 06:01, Paul Wise wrote:

>> gnome depends on apache ?
> 
> gnome-user-share uses apache2 to share files on the local network via WebDAV.

Is this an purely optional program, or does gnome itself depend on it ?

>> seriously ?
> 
> Sharing files with other computers on the local network seems like
> perfectly reasonable and useful feature to me. 

Okay. But WebDAV would be one of the last protocols, I'd consider
for that (maybe for the wide internet, but not for local networks).


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548117a8.9010...@gr13.net

mass hosting + cgi [WAS: Technical committee acting in gross violation of the Debian constitution]

[Enrico Weigelt, metux IT consult]

On 04.12.2014 22:23, Christoph Anton Mitterer wrote:

> Apart from that, when you speak of "non-trivial" quantities - I'd
> probably say that running gazillion websites from different entities on
> one host is generally a really bad idea.

No, it's not, and it's pretty cheap, if done right.

Several years ago, I was working for some large ISP (probably the
largest in Germany). Hosting more than 1000 sites per box, several
millions in total. (yes, most of them are pretty small and low
traffic).

IIRC at that time they've been using cgiexec. I just don't recall
why they didn't use my muxmpm. (maybe because apache upstream was
too lazy to pick it up, even though it had been shipped by several
large distros).

A few years earlier I've developed muxmpm for exactly that purpose:
a derivative of worker/perchild, running individual sites under their
own UID, spawning on-demand. This approach not just worked for CGI,
but also builtin content processor like mod_php, mod_perl, etc.

>>> FastCGI is just a slightly more fancy way of doing this.
>> FastCGI is another thing that almost nobody can afford when hosting 
>> a significant number of web sites.
> Why not?

It adds additional complexity, especially when you're going to manage
a _large_ number (several k) of users per box. In such scenarios
you wanna be careful about system resources like sockets, fds, etc.

I'm not up to date whether there's meanwhile an efficient solution
for fully on-demand startup (and auto-cleanup) of fcgi slaves
with arbitrary UIDs, and how much overhead copying between
processes (compared to socket-passing) produces on modern systems
(back when I wrote muxmpm, it still was quite significant)

OTOH, for high-volume scenarios, apache might not be the first choice.


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54811cde.5000...@gr13.net

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 25.11.2014 18:30, Stephen Gran wrote:

> Excellent.  I'm sure that if they can create a deb, they can install
> sysvinit, or runit, or some BSD, or whatever else they want.  A default
> is only a default, after all.

Just curious about the term "default":

Can I still install a system w/o systemd ever going into my system -
instead of replacing it later (eg. some option in the installer) ?


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54811f6d.7040...@gr13.net

Re: gnome depending on apache [WAS: Technical committee acting in gross violation of the Debian constitution]

[Paul Wise]

On Fri, Dec 5, 2014 at 10:25 AM, Enrico Weigelt wrote:

> Is this an purely optional program, or does gnome itself depend on it ?

Please review the dependencies of the gnome metapackage.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Ftkf0F6snR52XOyk_xhp9+CfX8gyHrsg2mYryf4=f...@mail.gmail.com

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 27.11.2014 00:29, Noel Torres wrote:

> manpower required to maintain a distribution with more than one init
> system widey installed, manpower to perform the required changes to
> support multiple init systems in Jessie, centered about the most
> important question: our users.

Just curious: how large actually is the overhead for that ?

For most packages, that IMHO should be just still writing/updating init
scripts parallel to systemd service descriptors. I haven't had the time
for a deeper analysis (systemd specifications aren't entirely precise
and complete ;-o), but maybe we could even generate them from an common
primary source, at least for a large portion of the cases.

But there are other cases like GNOME (and IIRC KDE), which now seem
to rely on systemd. I haven't done a deeper analysis what's exactly the
big deal about it, and why we now need a new init system (or parts of
it) for that. The most common argument I've heared from systemd folks is
the multi-seat issue.

Well, I'm maybe a bit old-fashioned, such setups aren't anything but
new to me (actually, done that 20 years ago), and I wonder what that
all has to do with the init system. The primary aspect here is a proper
Xserver configuration. We'll always have to support various unusual
setups, like multi-screen composition, multiple input devices, etc,
so just having multiple Xservers on separate screens seems a rather
simple sub-case. An hardcoded magic like systemd-logind does  (eg. it
generates it's own xserver configs on the fly) sounds like a pretty
bad idea to me. It might be working for a large number of users, but
also limits the whole stack to those rather simple scenarios.

The big question I'd ask the systemd and gnome folks is:

Why do these things all have to be so deeply interdependent ?
I would even question, why each DE needs it own display manager ?
What's so wrong with all the other DMs ?

Certain DEs (like GNOME and KDE) seem trying to build their own
operating system - I really fail to understand why.


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54812cc2.6080...@gr13.net

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 27.11.2014 11:18, Martin Steigerwald wrote:

>> Desktops (not only GNOME) use a very tiny bit of systemd, interfaces
>> that could be provided elsewhere. The real purpose of systemd is to
>> provide a modern init system.
> 
> I still wonder why there are provided within systemd then.

Same for me. If there really is some functionality which some DEs
really need, why not having an entirely separate tool for that ?

Anyways, I still didn't understand why udev is bundled within systemd.


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54812dae.9080...@gr13.net

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 27.11.2014 11:53, Matthias Urlichs wrote:

> Yes, the logind-related parte _could_ be provided elsewhere, but part of
> the features logind needs is already implemented in systemd. 

Can you understand, that this method is exactly one of the major reason
why many people dont like the systemd faction ?


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54812e53.9080...@gr13.net

Re: Technical committee acting in gross violation of the Debian constitution

[Nikolaus Rath]

"Enrico Weigelt, metux IT consult"  writes:
> On 27.11.2014 00:29, Noel Torres wrote:
>
>> manpower required to maintain a distribution with more than one init
>> system widey installed, manpower to perform the required changes to
>> support multiple init systems in Jessie, centered about the most
>> important question: our users.
>
> Just curious: how large actually is the overhead for that ?
>
> For most packages, that IMHO should be just still writing/updating init
> scripts parallel to systemd service descriptors. I haven't had the time
> for a deeper analysis (systemd specifications aren't entirely precise
> and complete ;-o), but maybe we could even generate them from an common
> primary source, at least for a large portion of the cases.

All this has been discussed extensively in the last 3 years, and it has
been attempted before that: https://wiki.debian.org/MetaInit.

> But there are other cases like GNOME (and IIRC KDE), which now seem
> to rely on systemd. I haven't done a deeper analysis
[...]

Other people have, and (again) it has been discussed extensively in the
least year. Please review the archives.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4qm67h4@vostro.rath.org

Re: Technical committee acting in gross violation of the Debian constitution

[Adam Borowski]

On Fri, Dec 05, 2014 at 05:02:27AM +0100, Enrico Weigelt, metux IT consult 
wrote:
> On 27.11.2014 11:53, Matthias Urlichs wrote:
> 
> > Yes, the logind-related parte _could_ be provided elsewhere, but part of
> > the features logind needs is already implemented in systemd. 
> 
> Can you understand, that this method is exactly one of the major reason
> why many people dont like the systemd faction ?

It looks like the's some interesting development based on ConsoleKit2,
such as LoginKit which translates CK2 calls to a logind-compatible API.

ConsoleKit2 itself appears to be a deep fork rather than just maintained
ConsoleKit(1), there's some internal overhaul and I heard rumours about
providing logind-compatible API directly (thus making the above LoginKit
obsolete).

So it looks there's hope we won't get saddled with systemd-logind.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141205051456.ga10...@angband.pl

Re: Technical committee acting in gross violation of the Debian constitution

[Adam Borowski]

On Fri, Dec 05, 2014 at 03:58:53AM +0100, Enrico Weigelt, metux IT consult 
wrote:
> On 25.11.2014 18:30, Stephen Gran wrote:
> 
> > Excellent.  I'm sure that if they can create a deb, they can install
> > sysvinit, or runit, or some BSD, or whatever else they want.  A default
> > is only a default, after all.
> 
> Just curious about the term "default":
> 
> Can I still install a system w/o systemd ever going into my system -
> instead of replacing it later (eg. some option in the installer) ?

With current d-i and/or debootstrap no, although you can give it an obscure
incantation that will replace systemd-sysv with sysvinit-core just
afterwards (leaving junk like systemd and its dependencies).

The latter can be fixed with a simple fix to --exclude (with a patch by
Kenshi Muto in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#20 )
but KiBi repeatedly keeps refusing that fix.

The former is less important as use cases that run d-i tend to be able to
boot with systemd (no custom kernel, no containers, etc) and thus getting
rid of it can be done as your regular after-install configuration.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141205053432.gb10...@angband.pl

Re: Please respect Freeze Policy

[Adam Borowski]

On Thu, Dec 04, 2014 at 10:08:38PM +0100, Niels Thykier wrote:
> Unfortunately, it is equally disruptive when people (despite best
> efforts) misjudge the consequences of their upload.  In such a case, you
> would be depriving your fellow co-Debianites from the opportunity of
> getting some patches into testing.
>   /This/ is why we recommend that people upload new upstream releases
> (etc.) to experimental.

Even if you disregard forcing fixes to go through t-p-u, uploads to unstable
do cause practical problems even for users of pure unstable.  For example,
thanks to libldb1, packages like samba, kde-runtime and many others are
uninstallable and will remain so for months.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141205054210.gc10...@angband.pl

Bug#772100: ITP: mimepull -- Java API to access attachments in a MIME message

[Tim Potter]

Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: mimepull
  Version : 1.9.4
  Upstream Author : Jitendra Kotamraju and Martin Grebac
* URL : https://mimepull.java.net
* License : CDDL 1.1, GPL2
  Programming Lang: Java
  Description : Java API to access attachments in a MIME message

The mimepull project provides a streaming API to access attachment
parts in a MIME message.  MIME message parsing is done using 
pull-parsing, much similar to StAX in XML world. The MIME parts are 
constructed lazily, and parsing is triggered by applications while 
reading the attachment parts.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141202073953.8.19370.reportbug@02ed91797728

Re: Technical committee acting in gross violation of the Debian constitution

[Russ Allbery]

"Enrico Weigelt, metux IT consult"  writes:

> Same for me. If there really is some functionality which some DEs really
> need, why not having an entirely separate tool for that ?

> Anyways, I still didn't understand why udev is bundled within systemd.

And I don't understand why you think your personal level of understanding
is interesting to the hundreds or thousands of people on this list.

Apparently, although you don't understand this, you don't care enough
about your lack of understanding to go do the mild amount of research
required to figure out why both of those decisions were made.  It's not
like anyone's hiding the reasoning.  Both decisions have been discussed
dozens of times over the past two years on this mailing list and many
other archived mailing lists around the Internet.  You could also just
politely ask the people who made those decisions if you really can't find
the answer.  (Being a polite person, I'm sure that you would understand
that an answer would be a favor to you, and wouldn't use that just as an
excuse to argue with people about their decisions.)

If you are curious and wanted to understand, there are many obvious
resources available for you to use.  You might not *agree* with the
decisions or the reasoning behind them, but that's not the same thing as
not *understanding*.

Please, either go do the research required to answer your own question, or
don't, but stop telling all the rest of us about your lack of
understanding.  At this point, this sort of message is essentially a
troll, since someone will see it, be unable to resist the urge to be
"helpful," try to explain the reasoning *yet again*, and off we'll go down
the same futile merry-go-round of argument.

Each time someone explains or asks for an explanation for the motivation
for systemd to them again, a kitten dies.  Please, think of the kittens.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx1atz1c@hope.eyrie.org

Re: Technical committee acting in gross violation of the Debian constitution

[Stephen Gran]

This one time, at band camp, Enrico Weigelt, metux IT consult said:
> On 25.11.2014 18:30, Stephen Gran wrote:
> 
> > Excellent.  I'm sure that if they can create a deb, they can install
> > sysvinit, or runit, or some BSD, or whatever else they want.  A default
> > is only a default, after all.
> 
> Just curious about the term "default":
> 
> Can I still install a system w/o systemd ever going into my system -
> instead of replacing it later (eg. some option in the installer) ?

I'm just curious as well.  Are you unable to do basic research, or are
you purposefully trolling to keep the conversation going?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature