You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2010/03/02 07:09:07 UTC
[vote] release 2.2.15?
Candidate at the usual /dev/dist/ URL; Your votes please...
+/-1
[ ] Release 2.2.15
I'll proceed to fight with win32 tomorrow, fighting with my linux vm was
enough fun for one day :)
Re: [vote] release 2.2.15?
Posted by Joe Orton <jo...@redhat.com>.
[+1] Release 2.2.15
Testing looks good on Fedora 12/x86_64. diff vs .14 is fine, sigs good,
CHANGES good. Thanks for RM-ing!
Minor note: a BOM has mysteriously appeared in CHANGES again :)
Regards, Joe
Re: [vote] release 2.2.15?
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1 (ugg BOM)
Re: [vote] release 2.2.15?
Posted by Jim Jagielski <ji...@apache.org>.
On Mar 3, 2010, at 9:28 AM, Dan Poirier wrote:
> [Non-binding] +1
> md5sums good
> sha1sums good
> pgp sig matches that in http://www.apache.org/dist/httpd/KEYS
>
> Mac OS 10.6.2 ("Snow Leopard"):
>
> No regressions from 2.2.14, though you still have to build with CC="cc
> -m32" to get a working server, and there are still test failures, but
> the same ones as in 2.2.14.
I use -arch i386 which is more wide-ranging and ensures some
capability with older libs
>
> Linux RHEL-5 x86:
>
> Built okay, all tests passed.
>
> Dan
>
Re: [vote] release 2.2.15?
Posted by Dan Poirier <po...@pobox.com>.
[Non-binding] +1
md5sums good
sha1sums good
pgp sig matches that in http://www.apache.org/dist/httpd/KEYS
Mac OS 10.6.2 ("Snow Leopard"):
No regressions from 2.2.14, though you still have to build with CC="cc
-m32" to get a working server, and there are still test failures, but
the same ones as in 2.2.14.
Linux RHEL-5 x86:
Built okay, all tests passed.
Dan
RE: [vote] release 2.2.15?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Dienstag, 2. März 2010 07:09
> To: Apache HTTP Server Development List
> Subject: [vote] release 2.2.15?
>
> Candidate at the usual /dev/dist/ URL; Your votes please...
>
> +/-1
> [ ] Release 2.2.15
>
>
> I'll proceed to fight with win32 tomorrow, fighting with my
> linux vm was
> enough fun for one day :)
>
>
+1 Tested on Solaris 8 / 9 / 10 SPARC RHEL 4 / 5, 32 / 64 Bit
Regards
Rüdiger
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 4:52 PM, Mladen Turk wrote:
> On 03/03/2010 11:45 PM, William A. Rowe Jr. wrote:
>> On 3/3/2010 4:44 PM, Mladen Turk wrote:
>>>
>>> Sure that could be the solution if there is no option to tell the
>>> server to make that decision.
>>
>> It's not the server's to make, this alert follows the TLS specification.
>
> Didn't meant that, but anyhow...
> Still doesn't smell "clean", but seems everyone else
> think this is not an issue, so fine with me.
If you want a workaround that is, in absolute terms, a server decision,
then we just ensure that an 'SSLAlertTimeout nnn' directive will accept
an argument of 0, timeout immediately.
Re: [vote] release 2.2.15?
Posted by Mladen Turk <mt...@apache.org>.
On 03/03/2010 11:45 PM, William A. Rowe Jr. wrote:
> On 3/3/2010 4:44 PM, Mladen Turk wrote:
>>
>> Sure that could be the solution if there is no option to tell the
>> server to make that decision.
>
> It's not the server's to make, this alert follows the TLS specification.
>
Didn't meant that, but anyhow...
Still doesn't smell "clean", but seems everyone else
think this is not an issue, so fine with me.
Regards
--
^TM
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 4:44 PM, Mladen Turk wrote:
>
> Sure that could be the solution if there is no option to tell the
> server to make that decision.
It's not the server's to make, this alert follows the TLS specification.
Re: [vote] release 2.2.15?
Posted by Mladen Turk <mt...@apache.org>.
On 03/03/2010 11:33 PM, William A. Rowe Jr. wrote:
>
>> Seriously, I was hoping 0.9.8m will reject legacy clients,
>> unless explicitly SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set,
>> but it seems that's not the case or we are doing something wrong in
>> mod_ssl.
>
> It rejects the renegotation. It is the callers responsibility to continue
> or die. Dr Henson's suggested approach is that we drop the timeout to
> some 5 seconds or less, in this case, until they resume the connection.
>
Sure that could be the solution if there is no option to tell the
server to make that decision.
Regards
--
^TM
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 4:04 PM, Mladen Turk wrote:
>
> while [ true ];
> do
> echo R | openssl s_client -connect host:port &
> done
>
> Not only it will kill the server, but it will kill your box as well :)
That's what IP tables is for. It's no different than
> while [ true ];
> do
> echo "OPTIONS * HTTP/1.1" | openssl s_client -connect host:port &
> done
demonstrating that your DoS concern is unfounded.
The hang *does* timeout, doesn't it?
I'm not arguing against a fix, I'm disputing your allegation of a DoS.
> Seriously, I was hoping 0.9.8m will reject legacy clients,
> unless explicitly SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set,
> but it seems that's not the case or we are doing something wrong in
> mod_ssl.
It rejects the renegotation. It is the callers responsibility to continue
or die. Dr Henson's suggested approach is that we drop the timeout to
some 5 seconds or less, in this case, until they resume the connection.
Assorted clients are known to trigger a renegotiation periodically (expired
their session?) and to not die but alert-and-continue helps this phone-browser
world.
Re: [vote] release 2.2.15?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Mar 2010, at 2:02 AM, William A. Rowe Jr. wrote:
>> If it causes the connection to hang, it is no different to just
>> telnetting to the server and talking enough of the protocol to keep
>> the
>> connection open for the full Timeout.
>
> Oh no - this is far more intensive; due to the cpu overhead of SSL
> handshaking.
> But as long as your server is accepting https: connections...
And the only way such a connection is possible is if the admin has
explicitly enabled https connections, in which case there is no
additional risk over the risk the admin already faces by virtue of
simply being plugged into the net.
Regards,
Graham
--
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 5:36 PM, Graham Leggett wrote:
> On 04 Mar 2010, at 12:04 AM, Mladen Turk wrote:
>
>> while [ true ];
>> do
>> echo R | openssl s_client -connect host:port &
>> done
>>
>> Not only it will kill the server, but it will kill your box as well :)
>
> If it causes the connection to hang, it is no different to just
> telnetting to the server and talking enough of the protocol to keep the
> connection open for the full Timeout.
Oh no - this is far more intensive; due to the cpu overhead of SSL handshaking.
But as long as your server is accepting https: connections...
Re: [vote] release 2.2.15?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Mar 2010, at 12:04 AM, Mladen Turk wrote:
> while [ true ];
> do
> echo R | openssl s_client -connect host:port &
> done
>
> Not only it will kill the server, but it will kill your box as well :)
If it causes the connection to hang, it is no different to just
telnetting to the server and talking enough of the protocol to keep
the connection open for the full Timeout.
That doesn't fit the definition of "kill the server".
If httpd/openssl/whatever started spinning, then it would be a whole
different matter, but I am assuming that isn't the case here.
Regards,
Graham
--
Re: [vote] release 2.2.15?
Posted by Mladen Turk <mt...@apache.org>.
On 03/03/2010 10:34 PM, William A. Rowe Jr. wrote:
> On 3/3/2010 2:00 PM, Mladen Turk wrote:
>>
>> Right, and I'm afraid if SSLInsecureRenegotiation (default) isn't set
>> while compiled with 0.9.8m one can easily create an DoS attack.
>
> Stop.
>
Weather I stop or not it will not make that disappear :)
>
> Please don't abuse words like DoS to describe utilization. Of course IE
> and Firefox, Opera and Safari are all DoS tools. It's called consuming
> server resources :)
>
while [ true ];
do
echo R | openssl s_client -connect host:port &
done
Not only it will kill the server, but it will kill your box as well :)
Seriously, I was hoping 0.9.8m will reject legacy clients,
unless explicitly SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set,
but it seems that's not the case or we are doing something wrong in mod_ssl.
Regards
--
^TM
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 2:00 PM, Mladen Turk wrote:
>
> Right, and I'm afraid if SSLInsecureRenegotiation (default) isn't set
> while compiled with 0.9.8m one can easily create an DoS attack.
Stop.
I can accomplish the same within the confines of the Timeout limitation
by connecting to the server, sending an OPTIONS line, and not completing
the request headers. The effect is the same.
Please don't abuse words like DoS to describe utilization. Of course IE
and Firefox, Opera and Safari are all DoS tools. It's called consuming
server resources :)
Re: [vote] release 2.2.15?
Posted by Mladen Turk <mt...@apache.org>.
On 03/03/2010 07:02 PM, William A. Rowe Jr. wrote:
> On 3/3/2010 11:50 AM, Stefan Fritsch wrote:
>> On Wednesday 03 March 2010, Mladen Turk wrote:
>>> BTW, I wouldn't recommend to compile against 0.9.8m.
>>> openssl s_client< 0.9.8m block on renegotiation
>>
>> Have you only tried 0.9.8l as client? It has a known bug with
>> renegotiation that makes it hang instead of fail.
>>
>> I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0).
>> If SSLInsecureRenegotiation is on, it works. If
>> SSLInsecureRenegotiation is off, I get an "sslv3 alert handshake
>> failure".
>
> And the bug is specific to openssl< 0.9.8m mishandling the alert; it will
> neither abort nor resume the prior session, so it is left to timeout. You
> may want to contrast this behavior to legacy IE, Firefox, etc.
>
Right, and I'm afraid if SSLInsecureRenegotiation (default) isn't set
while compiled with 0.9.8m one can easily create an DoS attack.
I might be wrong, but if the client is 0.9.8k it just stays
connected for server timeout. Sure it's disconnected if
SSLInsecureRenegotiation is set, but then what's the point?
Regards
--
^TM
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 4:41 PM, Joe Orton wrote:
> On Wed, Mar 03, 2010 at 11:21:47PM +0100, Mladen Turk wrote:
>> SSLInsecureRenegotiation off
>> echo R | openssl-0.9.8m s_client .. disconnects
>> echo R | openssl-0.9.8k s_client .. hangs until ServerTimeout
>
> Ah, right, hmm. Yes, this is exactly as Bill says, the client is
> ignoring the alert and then the server is hanging until a read times
> out. This consumes exactly the same amount of server resources as the
> client doing nothing with the connection.
>
> I'm not sure why the connection is not being forcibly closed by the
> server in this case, but:
>
> a) it's certainly not a security issue
> b) real clients don't initiate reneg, so it's not a practical issue
You were incorrect in your statement b) above;
http://marc.info/?l=openssl-dev&m=125873536926916&w=2
suggests real (handheld/phone) implementations that do this (or perhaps it
was really their proxy/gateway).
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 4:41 PM, Joe Orton wrote:
> b) real clients don't initiate reneg, so it's not a practical issue
^ OpenSSL
Note that other real clients based on other libraries aren't likely to share
the exact same flaw as OpenSSL in accepting the renegotiation failure or
terminating the connection if that wasn't an acceptable answer.
Re: [vote] release 2.2.15?
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Mar 03, 2010 at 11:21:47PM +0100, Mladen Turk wrote:
> SSLInsecureRenegotiation off
> echo R | openssl-0.9.8m s_client .. disconnects
> echo R | openssl-0.9.8k s_client .. hangs until ServerTimeout
Ah, right, hmm. Yes, this is exactly as Bill says, the client is
ignoring the alert and then the server is hanging until a read times
out. This consumes exactly the same amount of server resources as the
client doing nothing with the connection.
I'm not sure why the connection is not being forcibly closed by the
server in this case, but:
a) it's certainly not a security issue
b) real clients don't initiate reneg, so it's not a practical issue
Regards, Joe
Re: [vote] release 2.2.15?
Posted by Mladen Turk <mt...@apache.org>.
On 03/03/2010 11:01 PM, Joe Orton wrote:
> On Wed, Mar 03, 2010 at 06:31:36PM +0000, Dr Stephen Henson wrote:
>> If I understand the code correctly it looks like Apache is already
>> trapping and aborting client initiated renegotiations so this "hang"
>> situation shouldn't arise.
>
> This is true for client-initiated reneg, I'm not sure whether Mladen was
> talking about client- or server- initiated reneg, Mladen can you clarify
> exactly what problem you're seeing?
>
Very simple to duplicate, just find any <= 0.9.8k client
mod_ssl + openssl-0.9.8m
SSLInsecureRenegotiation on
echo R | openssl-0.9.8m s_client .. disconnects
echo R | openssl-0.9.8k s_client .. disconnects
SSLInsecureRenegotiation off
echo R | openssl-0.9.8m s_client .. disconnects
echo R | openssl-0.9.8k s_client .. hangs until ServerTimeout
Client reneg is rejected by our info callback
(which might be good or not, but that's not the point)
except with 0.9.8m and legacy clients.
Regards
--
^TM
Re: [vote] release 2.2.15?
Posted by Mladen Turk <mt...@apache.org>.
On 03/04/2010 12:29 AM, Joe Orton wrote:
> I'm fairly happy with refusing client-initiated reneg regardless.
>
+1
Explicit OpenSSL option
e.g. SSL_OP_DISABLE_CLIENT_INITED_RENEGOTIATION
would be helpful and we won't be needing info callback
in that case (which doesn't get called from SSL_CB_ACCEPT_LOOP
for legacy clients anyhow)
Regards
--
^TM
Re: [vote] release 2.2.15?
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Mar 03, 2010 at 10:40:34PM +0000, Dr Stephen Henson wrote:
> Joe Orton wrote:
> > On Wed, Mar 03, 2010 at 06:31:36PM +0000, Dr Stephen Henson wrote:
> >
> >> Note that you don't need to abort if secure renegotiation is supported
> >> by the client.
> >
> > Is there any technical need to support client-initiated reneg? It's a
> > bad fit with mod_ssl.
> >
>
> It has been reported that some clients (not OpenSSL based unless the application
> explicitly requests it) do renegotiate periodically. In one case sending back
> the no renegotiation alert to an unpatched client (*definitely* not OpenSSL
> based) meant the connection continued correctly.
Was this an HTTP client, do you have a reference for that? I was only
aware of use of SSL for protocols other than HTTP for which there were
known cases of client-initiated reneg.
> I've no idea how widespread this is though. It's something which just
> "worked" before and there'd be no reason to notice it.
For mod_ssl, e.g. I don't think things like SSLCipherSuite will be
enforced correctly for a client-initated reneg which didn't involve a
client cert request; there's no callback into mod_ssl to check it. So
I'm fairly happy with refusing client-initiated reneg regardless.
Regards, Joe
Re: [vote] release 2.2.15?
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
Joe Orton wrote:
> On Wed, Mar 03, 2010 at 06:31:36PM +0000, Dr Stephen Henson wrote:
>
>> Note that you don't need to abort if secure renegotiation is supported
>> by the client.
>
> Is there any technical need to support client-initiated reneg? It's a
> bad fit with mod_ssl.
>
It has been reported that some clients (not OpenSSL based unless the application
explicitly requests it) do renegotiate periodically. In one case sending back
the no renegotiation alert to an unpatched client (*definitely* not OpenSSL
based) meant the connection continued correctly.
I've no idea how widespread this is though. It's something which just "worked"
before and there'd be no reason to notice it.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: [vote] release 2.2.15?
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Mar 03, 2010 at 06:31:36PM +0000, Dr Stephen Henson wrote:
> If I understand the code correctly it looks like Apache is already
> trapping and aborting client initiated renegotiations so this "hang"
> situation shouldn't arise.
This is true for client-initiated reneg, I'm not sure whether Mladen was
talking about client- or server- initiated reneg, Mladen can you clarify
exactly what problem you're seeing?
> Note that you don't need to abort if secure renegotiation is supported
> by the client.
Is there any technical need to support client-initiated reneg? It's a
bad fit with mod_ssl.
Regards, Joe
Re: [vote] release 2.2.15?
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
William A. Rowe Jr. wrote:
> On 3/3/2010 11:50 AM, Stefan Fritsch wrote:
>> On Wednesday 03 March 2010, Mladen Turk wrote:
>>> BTW, I wouldn't recommend to compile against 0.9.8m.
>>> openssl s_client < 0.9.8m block on renegotiation
>> Have you only tried 0.9.8l as client? It has a known bug with
>> renegotiation that makes it hang instead of fail.
>>
>> I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0).
>> If SSLInsecureRenegotiation is on, it works. If
>> SSLInsecureRenegotiation is off, I get an "sslv3 alert handshake
>> failure".
>
> And the bug is specific to openssl < 0.9.8m mishandling the alert; it will
> neither abort nor resume the prior session, so it is left to timeout. You
> may want to contrast this behavior to legacy IE, Firefox, etc.
>
> Attached is one suggestion of a workaround.
>
>
If I understand the code correctly it looks like Apache is already trapping and
aborting client initiated renegotiations so this "hang" situation shouldn't arise.
Note that you don't need to abort if secure renegotiation is supported by the
client.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/3/2010 11:50 AM, Stefan Fritsch wrote:
> On Wednesday 03 March 2010, Mladen Turk wrote:
>> BTW, I wouldn't recommend to compile against 0.9.8m.
>> openssl s_client < 0.9.8m block on renegotiation
>
> Have you only tried 0.9.8l as client? It has a known bug with
> renegotiation that makes it hang instead of fail.
>
> I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0).
> If SSLInsecureRenegotiation is on, it works. If
> SSLInsecureRenegotiation is off, I get an "sslv3 alert handshake
> failure".
And the bug is specific to openssl < 0.9.8m mishandling the alert; it will
neither abort nor resume the prior session, so it is left to timeout. You
may want to contrast this behavior to legacy IE, Firefox, etc.
Attached is one suggestion of a workaround.
Re: [vote] release 2.2.15?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 03 March 2010, Mladen Turk wrote:
> BTW, I wouldn't recommend to compile against 0.9.8m.
> openssl s_client < 0.9.8m block on renegotiation
Have you only tried 0.9.8l as client? It has a known bug with
renegotiation that makes it hang instead of fail.
I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0).
If SSLInsecureRenegotiation is on, it works. If
SSLInsecureRenegotiation is off, I get an "sslv3 alert handshake
failure".
Re: [vote] release 2.2.15?
Posted by Mladen Turk <mt...@apache.org>.
On 03/02/2010 07:09 AM, William A. Rowe Jr. wrote:
> Candidate at the usual /dev/dist/ URL; Your votes please...
>
> +/-1
> [ X] Release 2.2.15
>
Win32/Win64/Fedora12/Solaris10
>
> I'll proceed to fight with win32 tomorrow, fighting with my linux vm was
> enough fun for one day :)
>
BTW, I wouldn't recommend to compile against 0.9.8m.
openssl s_client < 0.9.8m block on renegotiation
Regards
--
^TM
Re: [vote] release 2.2.15?
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Mar 2010, at 7:50 PM, William A. Rowe Jr. wrote:
>>> Candidate at the usual /dev/dist/ URL; Your votes please...
Tested ok on MacOSX v10.5, Centos 5.4 and RHEL 5.3.
+1.
Regards,
Graham
--
Re: [vote] release 2.2.15?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/2/2010 5:38 AM, Jeff Trawick wrote:
> On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>> Candidate at the usual /dev/dist/ URL; Your votes please...
>
> It is worth pointing out that
>
> * httpd 2.2.15 bundles APR 1.4.2 but continues to support APR 1.3.x.
> * Solaris users of httpd with unbundled APR 1.3.9 should upgrade APR
> to 1.3.12 or 1.4.2.
We will advise this in the announce; good point Jeff.
Re: [vote] release 2.2.15?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Candidate at the usual /dev/dist/ URL; Your votes please...
It is worth pointing out that
* httpd 2.2.15 bundles APR 1.4.2 but continues to support APR 1.3.x.
* Solaris users of httpd with unbundled APR 1.3.9 should upgrade APR
to 1.3.12 or 1.4.2.
Re: [vote] release 2.2.15?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Candidate at the usual /dev/dist/ URL; Your votes please...
>
> +/-1
[+1] Release 2.2.15
Solaris 10 U5/x86, Sun Studio, 32-bit and 64-bit builds, latest httpd
test suite successful (skipped tests for case_filter[_in], bucketeer,
echo, PHP)
Thanks!
Re: [vote] release 2.2.15?
Posted by Junyong Jiang <dr...@gmail.com>.
good news!
2010/3/2 William A. Rowe Jr. <wr...@rowe-clan.net>
> Candidate at the usual /dev/dist/ URL; Your votes please...
>
> +/-1
> [ ] Release 2.2.15
>
>
> I'll proceed to fight with win32 tomorrow, fighting with my linux vm was
> enough fun for one day :)
>
>
Re: [vote] release 2.2.15?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 02 March 2010, William A. Rowe Jr. wrote:
> Candidate at the usual /dev/dist/ URL; Your votes please...
>
> +/-1
> [+1] Release 2.2.15
Compiles and works on Debian unstable.
Re: [vote] release 2.2.15?
Posted by Mihai Moldovanu <mi...@tfm.ro>.
On Tuesday 02 March 2010 08:09:07 William A. Rowe Jr. wrote:
> Candidate at the usual /dev/dist/ URL; Your votes please...
>
> +/-1
> [ ] Release 2.2.15
>
>
> I'll proceed to fight with win32 tomorrow, fighting with my linux vm was
> enough fun for one day :)
Tested in TFM Linux 32/64
+1
--
Best regards,
Mihai Moldovanu
TFM Group Software
----------
Acest document apartine grupului de companii MPI / Pro Tv. Cu toate ca au fost luate masuri pentru a controla raspandirea virusilor, acest mesaj, impreuna cu orice atasament continut, este destinat numai pentru folosinta persoanei / persoanelor carora i se adreseaza si poate contine informatii confidentiale, care sunt supuse dreptului de autor sau constituie secret de marca. Daca nu sunteti destinatarul acestui mesaj, va notificam ca este strict interzisa orice transmitere, copiere sau distribuire a acestuia sau a oricarui atasament continut de acesta. Daca ati primit acest mesaj din greseala, va rugam sa ne anuntati imediat printr-un e-mail trimis la adresa postmaster@protv.ro
This document originates from within the MPI/Pro TV group of companies. Whilst we have taken steps to control the spread of viruses, this message together with any associated files, is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient of this communication you are hereby notified that any dissemination, copying or distribution of this message, or any files associated with this message, is strictly prohibited. If you have received this message in error, please notify us at once Mail to: postmaster@protv.ro
----------