Secure testing team - Oct 2007 - py-asterisk REMOVED from testing

Debian testing watch <noreply at henning.makholm.net> wrote:

Hi,

Could someone explain why py-asterisk and libasterisk-agi-perl got
pulled from testing due to security concerns in *asterisk* itself ?
>   Previous version: 0.1a3+r160-3
>   Current version:  (not in testing)
>   Hint: <http://ftp-master.debian.org/testing/hints/luk>
>     # 20071013
>     # Severe security concerns by Testing Security Team
>     Bug #434886: Remote compromise [CVE-2007-3762] [CVE-2007-3763]
[CVE-2007-3764] [CVE-2007-3765]
Both packages are libraries, for python and perl, to connect to the
asterisk manager, which can be local or remote. So there''s no
dependency on asterisk itself whatsoever.

Please put those two packages back into testing.

Thanks,

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <jblache at
debian.org>
 
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169

Julien BLACHE wrote:
> Debian testing watch <noreply at henning.makholm.net> wrote:
> 
> Hi,
Hi
> Could someone explain why py-asterisk and libasterisk-agi-perl got
> pulled from testing due to security concerns in *asterisk* itself ?
Because asterisk maintainers apparantly aren''t interesting in making 
sure stable and secure packages reach testing as this is already taking 
months and even before the release these packages were more than once in 
a very bad shape, I thought they wouldn''t mind... I guess I was wrong, 
though I can still be convinced to remove all their packages from 
testing if I was right after all...
> Both packages are libraries, for python and perl, to connect to the
> asterisk manager, which can be local or remote. So there''s no
> dependency on asterisk itself whatsoever.
> 
> Please put those two packages back into testing.
Ok, purged removal hints for these two for now...

Please, pretty please can someone preferably more than one take care of 
the VOIP packages appropriately so removals of testing and release team 
wasting time on them is not necessary anymore, TIA!

Cheers

Luk

Luk Claes wrote:
> Because asterisk maintainers apparantly aren''t interesting in
making
> sure stable and secure packages reach testing as this is already taking 
> months and even before the release these packages were more than once in 
> a very bad shape, I thought they wouldn''t mind... I guess I was
wrong,
> though I can still be convinced to remove all their packages from 
> testing if I was right after all...
><snip>
> Please, pretty please can someone preferably more than one take care of 
> the VOIP packages appropriately so removals of testing and release team 
> wasting time on them is not necessary anymore, TIA!
I have tried fixing all of the security bugs of asterisk.
We''ve already had security uploads on both sarge and etch recently
(DSA-1358-1)

Unfortunately, asterisk in lenny was FTBFSing because of missing or
changed dependencies so I couldn''t make an upload to testing-security,
even though the version is exactly the same as of etch.

Since then, I''m trying to get asterisk to migrate with no success.
We''ve had many problems unrelated to asterisk itself that had to fix or
workaround, such as a binutils bug (#440015) a gcc-4.2 bug (#445336)
and, of course, the lbl128 transition.

Asterisk is quite hard to get to testing because of the vast amount of
build-deps. Right now, it''s blocked by net-snmp, perl, krb5 and
gtk-2.0.

I had hoped that it would be in testing over a month ago and that''s why
I didn''t request its removal from testing.
Security team (Moritz and Stefan) were aware of that when we discussed
the upload for sarge/etch.

If you think there are some other pending issues, please say so and I
will handle them personally.

Regards,
Faidon

Luk Claes <luk at debian.org> wrote:

Hi,
>> Could someone explain why py-asterisk and libasterisk-agi-perl got
>> pulled from testing due to security concerns in *asterisk* itself ?
>
> Because asterisk maintainers apparantly aren''t interesting in
making
> sure stable and secure packages reach testing as this is already taking 
> months and even before the release these packages were more than once in 
> a very bad shape, I thought they wouldn''t mind... I guess I was
wrong,
> though I can still be convinced to remove all their packages from 
> testing if I was right after all...
I have trouble understanding why you''ve removed unrelated
packages. asterisk has security issues, you pull it from testing along
with dependent packages, end of the story. Why remove other packages
that have no relationship with asterisk as far as the testing scripts
are concerned ?

Even if we were to ship a stable release without asterisk itself,
packages like py-asterisk and libasterisk-agi-perl are still useful.
> Ok, purged removal hints for these two for now...
Thanks !
> Please, pretty please can someone preferably more than one take care of 
> the VOIP packages appropriately so removals of testing and release team 
> wasting time on them is not necessary anymore, TIA!
I understand why you''re pissed at asterisk. I am too. But this is
being worked on and some people are putting a lot of energy into
that. In the meantime, please avoid collateral damages :)

Thanks,

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <jblache at
debian.org>
 
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169

Faidon Liambotis wrote:
> Luk Claes wrote:
>> Because asterisk maintainers apparantly aren''t interesting in
making
>> sure stable and secure packages reach testing as this is already taking
>> months and even before the release these packages were more than once
in
>> a very bad shape, I thought they wouldn''t mind... I guess I
was wrong,
>> though I can still be convinced to remove all their packages from 
>> testing if I was right after all...
>> <snip>
>> Please, pretty please can someone preferably more than one take care of
>> the VOIP packages appropriately so removals of testing and release team
>> wasting time on them is not necessary anymore, TIA!
> I have tried fixing all of the security bugs of asterisk.
> We''ve already had security uploads on both sarge and etch recently
> (DSA-1358-1)
> 
> Unfortunately, asterisk in lenny was FTBFSing because of missing or
> changed dependencies so I couldn''t make an upload to
testing-security,
> even though the version is exactly the same as of etch.
It was FTBFSing because of a removed build dependency which apparantly 
was fixed in unstable but not in testing...
> Since then, I''m trying to get asterisk to migrate with no success.
> We''ve had many problems unrelated to asterisk itself that had to
fix or
> workaround, such as a binutils bug (#440015) a gcc-4.2 bug (#445336)
> and, of course, the lbl128 transition.
Which is of course a bit late, but thanks for trying to sort out the 
mess anyway!
> Asterisk is quite hard to get to testing because of the vast amount of
> build-deps. Right now, it''s blocked by net-snmp, perl, krb5 and
gtk-2.0.
That means you should try to get a stable version into testing and keep 
that maintained for library transitions while you prepare and stabilise 
a next candidate for stable (new upstream and/or less important changes) 
in experimental and coordinate with maintainers of these build-deps on 
when it''s a good time to upload it to unstable... IMHO
> If you think there are some other pending issues, please say so and I
> will handle them personally.
The issue now is that people cannot install asterisk in testing and 
people who already have it installed have a vulnerable version... though 
I''m confident you''ll try to fix that ;-)

Cheers

Luk

Luk Claes wrote:
>> Unfortunately, asterisk in lenny was FTBFSing because of missing or
>> changed dependencies so I couldn''t make an upload to
testing-security,
>> even though the version is exactly the same as of etch.
> 
> It was FTBFSing because of a removed build dependency which apparantly 
> was fixed in unstable but not in testing...
There were other issues too, regarding zaptel; different libtonezone-dev
for example.
>> Asterisk is quite hard to get to testing because of the vast amount of
>> build-deps. Right now, it''s blocked by net-snmp, perl, krb5
and gtk-2.0.
> 
> That means you should try to get a stable version into testing and keep 
> that maintained for library transitions while you prepare and stabilise 
> a next candidate for stable (new upstream and/or less important changes) 
> in experimental and coordinate with maintainers of these build-deps on 
> when it''s a good time to upload it to unstable... IMHO
Remember, we''re not having issues with RC bugs of asterisk; if
anything,
many bugs are *closed* with each version.
Upstream has freezed new features for the 1.4 series and are focusing on
1.5/1.6 and we don''t have ground-breaking changes with new versions.
These are being carefully examined and packaged because they solve bugs
(1.4.13.1 fixed a few memory corruption bugs and some deadlock bugs,
1.4.13 and 1.4.12 fixed security bugs).

And coordinating *at the same time* with the maintainers of net-snmp,
perl, krb5 and gtk-2.0 is impossible, IMHO.
BTW, I''m subscribed to d-d-a and d-release. Noone informed anyone about
these transitions -- net-snmp even broke the build-dep in a way that
wasn''t easily spotted (pbuilder worked while sbuild failed) and
didn''t
say anything. But I''m sure you know about these things.
>> If you think there are some other pending issues, please say so and I
>> will handle them personally.
> 
> The issue now is that people cannot install asterisk in testing and 
> people who already have it installed have a vulnerable version... though 
> I''m confident you''ll try to fix that ;-)
You''re right and I feel bad about it.
And for those people, I can only suggest to add *stable* security to
their sources.list to get a non-vulnerable version, unfortunately.

Everyone is breaking stuff in unstable uncoordinated at a rate that
it''s
hard to get complicated packages to migrate, though I''m confident you
know that and you''re trying to fix it ;-)

Thanks,
Faidon