Re: announce mails

2021-12-21 Thread Nick Edwards
Oh, right, then we can delete our mirror then, thats get a few gigabytes
back

its not an issue for us, since we are not permitted to perform any upgrades
since we are within the christmas embargo period, but the home users who
run apache might be seeking out their fave stale mirror :)


On Tue, Dec 21, 2021 at 4:31 PM Greg Stein  wrote:

> The mirror system is no longer used. Most downloads are processed through
> a CDN instead. European downloaders will tend to hit downloads.apache.org
> which is "instantly" updated once a release artifact is committed to the
> svn distribution repository.
>
> rsync.apache should be just as instant. If not, then please file an INFRA
> ticket.
>
> Cheers,
> -g
>
>
> On Mon, Dec 20, 2021 at 7:26 PM Nick Edwards 
> wrote:
>
>> Why would the release system initiate an announce when the mirrors are
>> not up to date, they cant be, since rsync.apache still lists 2.4.51 as
>> latest, the process is to allow time for mirrors to get the package before
>> announcing it
>>
>>
>> On Mon, Dec 20, 2021 at 7:53 PM Stefan Eissing 
>> wrote:
>>
>>> The mailings to announce lists continue to bother me. The release
>>> announcement is the the moderation queue (hopefully) and the cveprocess
>>> mails go right through to the list. This is not the order I prefer.
>>>
>>> I am holden back the send about the second CVE until I see the release
>>> announcement winked through.
>>>
>>> - Stefan
>>
>>


Re: announce mails

2021-12-20 Thread Nick Edwards
Why would the release system initiate an announce when the mirrors are not
up to date, they cant be, since rsync.apache still lists 2.4.51 as latest,
the process is to allow time for mirrors to get the package before
announcing it


On Mon, Dec 20, 2021 at 7:53 PM Stefan Eissing  wrote:

> The mailings to announce lists continue to bother me. The release
> announcement is the the moderation queue (hopefully) and the cveprocess
> mails go right through to the list. This is not the order I prefer.
>
> I am holden back the send about the second CVE until I see the release
> announcement winked through.
>
> - Stefan


Re: release vibes?

2021-12-10 Thread Nick Edwards
Release often?  let me tell you of a story from a System Administrators
perspective as to why thats bad and should be avoided and you should learn
from other people's mistakes

There is a reason sysads dislike developers, they have this "oh new code
gotta push it out right away" mentality, but we push back saying nope we
just did your upgrade it can wait will another one, and the golden rule is
nobody updates anything during the christmas "embargo" period which I
believe Noel was referring to, this generally is from two weeks before
Christmas, til two weeks after the start of the New Year.

There was once this young guy who developed this shiny new yet highly
popular internet daemon, in its infancy it was a wizzbang and everybody
loved it and was moving to it, the problem soon arose that every new
feature was pushed out, and as murphy dictates, problem be found, sometimes
sysads were having to update this highly popular software every few weeks,
sometimes more, there was even a few times we recall having to update it
three times in just ONE week because of this push push push mentality, this
results in a large percentage of sysads pushing back and refusing to test
let alone update, over time this continued, new releases every few weeks,
tiresome - like we have nothing better to do but upgrade the same software
over and over and over, wasn't going to happen, and didn't happen, some of
these were to fix nasty exploitable problems, but almost nobody bothered
because "jesus christ another bloody update"... a lot of people were burned.

That same project did get a lot better with a rewrite of its code and a
move to a new "major release" the updates still came, but not thick and
fast, this made sysads much happier, the developer had learned push often
is not what system and network operators want, now days sysads love that
project, it releases every few months on average which we can accept and
has much fewer bugs, and rarely anything severe.

That project, is called   dovecot



On Wed, Dec 8, 2021 at 1:17 AM Mladen Turk  wrote:

>
>
> On 06/12/2021 11:36, Stefan Eissing wrote:
> > Friends of httpd, how do you feel about a release in the next two weeks?
> >
>
> +1
> Release early, release often
>
> Regards
> --
> ^TM
>


Re: TLSv1.3

2018-04-02 Thread Nick Edwards
well well if its not BANNED USER  Reindl harrold using a ghost account


On Tue, Apr 3, 2018 at 5:02 AM, li...@rhsoft.net  wrote:

>
>
> no, it's just an opinion based on the Chrome will penalty non-https in
> general (bseides: the ACME challenge is happy with a automatic rediect
> to https even if it's a self-signed certificate)
>
> that opinion completly ignores setups where the load-balancer does
>


Re: Listen 443 https (SSLEngine Optional - dual host)

2017-09-16 Thread Nick Edwards
phpmyadmin 4.4.15  is YEARS old

we using 4.7 for nearly a year, 4.7.2 is current

this from a troll who verbally abuses the hell out of people on other lists
for posting similar comments using very outdated softwares   HAH, this ones
in google for life.


On Sun, Sep 17, 2017 at 10:24 AM, Reindl Harald 
wrote:

>
> that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something
> wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some bad
> code using that var instead of $_SERVER['HTTPS'] which again leaded in a
> endless loop
>
> in case of phpMyAdmin it redirects to https://hostname:80/path/ after
> enter username/password - the workaround below in the config file seems to
> solve that for now, but all in all that leaves a very bad taste
>
> if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
> {
>  $cfg['ForceSSL'] = false;
> }
> else
> {
>  $cfg['ForceSSL'] = true;
> }
>
>
> Am 14.09.2017 um 18:16 schrieb Reindl Harald:
>
>> Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
>>
>>> Ok, as I read the code a bit more, there is a tangle of things that can
>>> influence port/scheme selection. But what I can see, the version in *trunk*
>>> should do the right thing *iff*
>>>
>>> a) you use "SSLEngine *:443" instead of "Optional"
>>> b) you use "ServerName xxx.yyy" *without* a port name
>>>
>>> the a
>>> 
>>>ServerName xxx.yyy
>>>SSLEngine *:443
>>> ...
>>> 
>>>
>>> should do the right thing here. Internal methods used to generator
>>> Redirect Location headers, namely
>>> ap_construct_url()
>>> ap_get_server_port()
>>> ap_http_scheme()
>>> should give back the correct values for each connection and als fill the
>>> Env Variables with the correct values.
>>>
>>
>> what means "trunk" here?
>> a future 2.5/2.6/3.0 or a 2.4.x in the near future?
>>
>> within 2 weeks you need TLS on each and every host since Chrome starts to
>> warn about every page with a form tag and no TLS
>>
>> [root@srv-rhsoft:~]$ apachectl -t
>> AH00526: Syntax error on line 29 of /etc/httpd/conf/sites_enabled/
>> contentlounge.conf:
>> Argument must be On, Off, or Optional
>>
>>> Am 14.09.2017 um 15:46 schrieb Reindl Harald :



 Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

> Harald,
> could you check if a configuration like:
>UseCanonicalPhysicalPort on
> in the server or vhost mitigates the problem?
>

 it makes it even more terrible and the resulting http:// protocol
 instead https// on port 443 here even tiggers mod_security

 even if it would mitigate that issue - having ports in redirect urls
 easily leads to a lot of other problems when proxy-servers are part of the
 game

 [harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure
 https://contentlounge/cms
 HTTP/1.1 301 Moved Permanently
 Date: Thu, 14 Sep 2017 13:43:06 GMT
 X-DNS-Prefetch-Control: off
 X-Content-Type-Options: nosniff
 X-Response-Time: D=1561 us
 Location: http://contentlounge:443/cms/
 Cache-Control: max-age=0
 Expires: Thu, 14 Sep 2017 13:43:06 GMT
 Content-Type: text/html; charset=iso-8859-1

 Am 14.09.2017 um 12:00 schrieb Reindl Harald :
>>
>>
>>
>> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>
>>> If you want to experiment...
 
 is already recognized

>>> but with "SSLEngine On" and "SSLCertificateFile" configured
>>> non-https no longer would work
>>>
>>
>> OK, figured it out
>>
>> * you need the *first* vhost with "SSLEngine On"
>> * others can have "SSLEngine optional" and listen to 80 and 443
>>
>> but there is a bug: https://bz.apache.org/bugzilla
>> /show_bug.cgi?id=61519
>>
>> if the trailing slash is missing in the url the automatic redirect to
>> the full qualified folder-path points to http:// instead https://
>> and that does not happen within a vhost dedicated to :443 and "SSLEngine 
>> On"
>>
>> i was trapped in a endless loop because the php script making a
>> redirect to https:// had a bug and missed the traling / too
>>
>> 
>> DocumentRoot "/www/contentlounge"
>> ServerName contentlounge.rhsoft.net
>> SSLEngine optional
>> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
>> 
>>
>> [harry@srv-rhsoft:~]$ curl --head --insecure
>> https://contentlounge/cms
>> HTTP/1.1 301 Moved Permanently
>> Date: Thu, 14 Sep 2017 09:40:27 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=1311 us
>> Location: http://contentlounge/cms/
>> Cache-Control: max-age=0
>> Expires: Thu, 14 Sep 2017 09:40:27 GMT
>> Content-Type: text/html; charset=iso-8859-1
>>
>


Re: [proposed] 2.4 Maintenance SIG

2017-01-27 Thread Nick Edwards
You need some edumacation, I've avoided getting involved in these comments
but I think this has to be said.

Reindl is a long time well known troll, a highly caustic and abusive one,
he's been kicked off more industry mailing lists than you've probably had
hot dinners for it, some other lists, he's just moderated on, but replies
constantly to posters in private, he also abuses them in private, this led
to him being blacklisted in a DNSBL that Noel happens to be one of the
maintainers of, so Reindl constantly tries to bait him, I heard they
mutually had agreement never to talk to each other, but Reindl does not
know how to keep promises, especially when others come out against Noel
like has gone on here, Reindl will always be in it (you vna see this from
his usual lame comment), I'm not  a real fan of Noel, I know him
personally, I worked for him in a national ISP - before he sacked me :)
He's a decent guy who will go out his way to help others, truth be told I
probably had a bout 10 warnings where most get 3 so he has a lot patience,
but if he has an opinion he will always express it and wont walk on cotton
wool in doing so, some respect him for it, others detest him for it, he's
always told me he doesnt care, because at least people know where they
stand with him.


as for Reindl, well, he cant see what hes doing wrong, despite being kicked
off all those lists, he's just a lost cause.
this ends your edumacation.


On Sat, Jan 28, 2017 at 12:11 AM, Eric Covener  wrote:

>
> On Fri, Jan 27, 2017 at 6:22 AM, Noel Butler 
> wrote:
>
>> I never object to any sensible opinion.
>>
>> Harry, you were warned never to reply or respond to me, because you know
>> what happens if you do, i'll assume you were off your meds again when you
>> clicked reply and forgot.
>>
> You both need to keep it topical and stop the mutual harassment.  Enough
> is enough.
>


Re: Status for 2.4.20

2016-03-30 Thread Nick Edwards
So after a thread stop message, why do you feel you need to troll bait them?
It's clear they both agreed to ignore each other, it's been clear one party
had no intention on keeping his word (having had myriad of clashes with the
fool reindl myself on other lists I'm not at all surprised he expected it
to all one way), so the other advises " gates of hell will open ", so,
what's your angle? what's the point of your post, posts like yours only
invites trouble. If they don't want to adhere to thread stop William will
wield his big stick as he clams to have, their problem.



On Wed, Mar 30, 2016 at 8:15 AM, Yann Ylavic  wrote:

> On Wed, Mar 30, 2016 at 7:49 AM, William A Rowe Jr 
> wrote:
> > FULL STOP.
>
> Really, NOW, simply don't talk to each other here (this way at least,
> but anyway is fine too since it seems hopeless).
>
> You are able to block each other on your respective networks, well,
> keep reading your logs for bounced emails if it pleases you, but this
> list (or any @a.o one) is definitively not an loop-hole!
>


Re: [VOTE] Release Apache httpd 2.4.12 as GA

2015-01-27 Thread Nick Edwards
On 1/27/15, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 Hi Nick, Noel,

 I presume you are each running mod_php (and not php's fcgi sapi)?
 Are you doing so with prefork mpm, or the win32/worker mpm?  Did
 you build php TS?


I am  running mod_php yes,prefork, and php TS.

 Did you update any aspect of php between your 2.4.10 and 2.4.12
 test cases?




 On Mon, 26 Jan 2015 11:23:20 +1000
 Noel Butler noel.but...@ausics.net wrote:


 On 25/01/2015 17:21, Nick Edwards wrote:

  I am noticing a number of hits using UTC with this version?
  Not all, only some, is anyone else seeing this?
  Does not occur on 2.4.10.
  They are php pages, however, the main site which is php is static,
  it only uses php for counter nothing else, its all hard written in
  vi.
 
  On 1/23/15, Jim Jagielski j...@jagunet.com wrote:
 
  The pre-release test tarballs for Apache httpd 2.4.12 can be found
  at the usual place: http://httpd.apache.org/dev/dist/ [1] I'm
  calling a VOTE on releasing these as Apache httpd 2.4.12 GA. [ ]
  +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why.
  Vote will last the normal 72 hrs. NOTE: The *-deps are only there
  for convenience. Thx!

 Hrmm, I also see this,

 170.130.179.246 - - [26/Jan/2015:01:02:06 +] GET /archives/
 197.156.95.99 - - [26/Jan/2015:11:02:18 +1000] GET /ups/t568b.png
 HTTP/1.1
 95.211.138.225 - - [26/Jan/2015:01:02:40 +]
 GET /Android-Apps.html HTTP/1.1
 144.76.247.107 - - [26/Jan/2015:11:03:32 +1000] GET /

 (correct time is 11:xx:xx)

 My first thought was php - it's been known in the past to be this type
 of offender however I have timezone set in the ini, not to mention
 I've been running 5.5.20 since its release and going back a few weeks
 in master logs I see it only occurring since 2.4.12 was installed and
 I also see it on other sites, one of which is written in ruby, and a
 static HTML site, so that rules out php at fault (for once LOL), since
 only one box (my private one) is running 2.4.12, I checked a few other
 servers on 2.4.10 and can see no sign of this UTC logging.

 So, until I have time to look further I withdraw my N/B Good to go



 Links:
 --
 [1] http://httpd.apache.org/dev/dist/




Re: [VOTE] Release Apache httpd 2.4.12 as GA

2015-01-24 Thread Nick Edwards
I am noticing a number of hits using UTC with this version?
Not all, only some, is anyone else seeing this?
Does not occur on 2.4.10.
They are php pages, however, the main site which is php is static, it
only uses php for counter nothing else, its all hard written in vi.


On 1/23/15, Jim Jagielski j...@jagunet.com wrote:
 The pre-release test tarballs for Apache httpd 2.4.12 can be found
 at the usual place:

   http://httpd.apache.org/dev/dist/

 I'm calling a VOTE on releasing these as Apache httpd 2.4.12 GA.

 [ ] +1: Good to go
 [ ] +0: meh
 [ ] -1: Danger Will Robinson. And why.

 Vote will last the normal 72 hrs.

 NOTE: The *-deps are only there for convenience.

 Thx!



Re: Use of HTML on mailing lists (Re: SO_REUSEPORT in the children processes)

2014-03-09 Thread Nick Edwards
Truer words were never spoken about Harald Reindl, this person brings
trouble to every mailing list he joins

postfix - banned
fedora - moderation
centos - moderation/banned
roundcube - moderation
dovecot - final warnings

and they are just the lists I know of, and when moderated he is known
to send direct abuse and threats to people (this is why on roundcube
he will never be post status again)

removing the content of such deserved vulgar (about time somebody gave
him a dose of his own medicine for once) I do not find his hostname in
bl.alt-backspace.org so, if thats a fabrication, well, I'll leave it
to your imaginations.

I suggest this list moderates him as well else this is just the start
of things to come going by his very poor track record. Most  people
(myself included) have him filtered out anyway- now he's found his way
onto this list, I no longer whitelist this list.


suexec privilege elevation

2013-08-08 Thread Nick Edwards
As per FD list post..

Does this seem valid?

FWD MESSAGE


Apache suEXEC privilege elevation / information disclosure

Discovered by Kingcope/Aug 2013

The suEXEC feature provides Apache users the ability to run CGI and SSI programs
under user IDs different from the user ID of the calling web server. Normally,
when a CGI or SSI program executes, it runs as the same user who is running the
web server.
Used properly, this feature can reduce considerably the security risks involved
with allowing users to develop and run private CGI or SSI programs.

With this bug an attacker who is able to run php or cgi code inside a web
hosting environment and the environment is configured to use suEXEC as a
protection mechanism, he/she is able to read any file and directory on the file-
system of the UNIX/Linux system with the user and group id of the
apache web server.

Normally php and cgi scripts are not allowed to read files with the apache user-
id inside a suEXEC configured environment.

Take for example this apache owned file and the php script that follows.

$ ls -la /etc/testapache
-rw--- 1 www-data www-data 36 Aug  7 16:28 /etc/testapache
only user www-data should be able to read this file.

$ cat test.php
?php
system(id; cat /etc/testapache);
?

When calling the php file using a webbrowser it will show...
uid=1002(example) gid=1002(example) groups=1002(example)

because the php script is run trough suEXEC.
The script will not output the file requested because of a permissions error.

Now if we create a .htaccess file with the content...
Options Indexes FollowSymLinks

and a php script with the content...

?php
system(ln -sf / test99.php);
symlink(/, test99.php); // try builtin function in case when
//system() is blocked
?
in the same folder

..we can access the root filesystem with the apache uid,gid by
requesting test99.php.
The above php script will simply create a symbolic link to '/'.

A request to test99.php/etc/testapache done with a web browser shows..
voila! read with the apache uid/gid

The reason we can now read out any files and traverse directories owned by the
apache user is because apache httpd displays symlinks and directory listings
without querying suEXEC.
It is not possible to write to files in this case.

Version notes. Assumed is that all Apache versions are affected by this bug.

apache2 -V
Server version: Apache/2.2.22 (Debian)
Server built:   Mar  4 2013 21:32:32
Server's Module Magic Number: 20051115:30
Server loaded:  APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture:   32-bit
Server MPM: Worker
  threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with
 -D APACHE_MPM_DIR=server/mpm/worker
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT=/etc/apache2
 -D SUEXEC_BIN=/usr/lib/apache2/suexec
 -D DEFAULT_PIDLOG=/var/run/apache2.pid
 -D DEFAULT_SCOREBOARD=logs/apache_runtime_status
 -D DEFAULT_ERRORLOG=logs/error_log
 -D AP_TYPES_CONFIG_FILE=mime.types
 -D SERVER_CONFIG_FILE=apache2.conf

___


suexec and reload modules

2013-05-24 Thread Nick Edwards
Hi,

Two questions

First, when apache gracefully reloads, it does not reload the modules?
is there an option to have it fully reloads them? or, is an option
planned?

Case: We use mod cband to control clients speed and limits, but if we
alter their configuration to increase the speed, reload does not
change it, only a full stop, and start changes. So pewrhaps a feature
request?

Second, SuExec, is there plan to modify suexec so docroot build option
is the absolute root of what can be accessed, similar to using
php_admin_value open_basedir  which locks down (yes I know it does its
best but rogue modules may break out of this) so users can not
traverse parent directories.

If apache/php can do its best to lock down php with no noticable
resource impact, can not understand why the main programme, apache,
can not either - without creating the nightmare that is jails, or
relying on third party modules like mod security, which have had
problems of their own, and even some configurations, like ours, mod
security is not by their own worlds, suited to our needs.

I know suexec hardens things up a little, and stops,. or at least
tracks who is being naughty, but, prevention is better than the cure.


scorebord permissions

2012-09-01 Thread Nick Edwards
Hello,

I have an issue where, apache is, when using graceful reload, setting
perms for domains as root

-rw---  1 root   root 44 Sep  1 05:59 somedomain


yet if I delete this and either   click on URL, or, stop apache and
cleanly start apache it is recreated cleanly as:

-rw---  1 apache   apache 44 Sep  1 06:00 somedomain

stop/start/reload are all called from the same sh file.

This behaviour also exists when using  apachectl directly

Is this a bug?


Re: Choosing a stronger password hash algorithm

2012-07-12 Thread Nick Edwards
Away on holidays, late reply, apologies.

I would like to see bcrypt introduced, a number of sites seem to be
moving that way, would be nice if apache did too!


On 6/24/12, Stefan Fritsch s...@sfritsch.de wrote:
 On Saturday 23 June 2012, William A. Rowe Jr. wrote:
 On 6/23/2012 3:42 PM, Stefan Fritsch wrote:
  bcrypt [1] and scrypt [2] seem to be much more difficult to port
  to hardware or GPUs than sha256/512_crypt [3-5]. We can't make
  the operation too expensive on normal CPUs or we create a DoS
  problem if someone does lots of requests with wrong passwords.
  Therefore I think choosing an algorithm that does not scale well
  on more specialized hardware is good.
 
  Both bcrypt and scrypt can be adjusted in how much CPU time to
  use. scrypt can also be adjusted in how much RAM it uses. bcrypt
  uses a 128bit salt, AFAICS scrypt can use arbitrary salt
  lengths.
 
  Bcrypt has seen a lot more review than scrypt, therefore I am
  somewhat in favor of bcrypt. Crypt_blowfish [6] is an
  implementation with a very liberal license that we could use.
  Scrypt has a 2-clause BSD license which would also be OK.
 
  Opinions?

 We already have integration points to openssl, why add yet another
 dependency?  Seems foolish.

 Openssl is not required, neither for apr nor for httpd. I propose to
 import either crypt_blowfish or scrypt into apr, just like apr
 contains some foreign sha1 and md5 code. This way we would not get an
 additional external dependency.



Re: md5crypt passwords

2012-06-21 Thread Nick Edwards
Hi Stefan,

On 6/21/12, Stefan Fritsch s...@sfritsch.de wrote:
 On Wed, 20 Jun 2012, Nick Edwards wrote:
 I posted this to users list last week but no-one bit, so I'm trying here.

 With md5crypt no longer recommended for use by its author, will Apache
 soon support sha256/sha512 in basic authentication via MySQL.

 Note that it does not really matter that much which hash algorithm is
 used. The number of rounds is more important. APR-MD5 ($apr1$) does 1000
 times recursive md5 (which is 1000 times more secure in terms of brute
 forcing than plain md5). We should switch to something that needs more
 processing time so that it is more difficult to brute force.

 I understand the apr version is different to plain md5crypt, but it is
 based on the same thing from what I can tell, so its pointless
 upgrading our database passwords to use sha512 if Apache's still the
 weak link.

 All admin scripts run in perl, and we are currently doing this with
 apache_md5_crypt($password); using Crypt::PasswdMD5

 For Mail and FTP, we are _now_ successfully using  crypt($password,
 '$6$' . $16charsalt) for sha512, be nice if Apache basic auth would
 too!

 APR passes everything it doesn't know to the system's crypt() function. So
 chances are good that using $6$... already works for you. However, there
 is currently no way to create such hashes with htpasswd.



Thanks, it does work, I did not realise this, because some time ago I
tried to use our default md5cryprt password used for ftp and mail, but
Apache did not like it, after much googling I found reference saying
it was different and needed apr1, if it falls back why would that have
failed for us? or is this fallback only something new?



 I would be for importing some state of the art scheme from some BSD. Good
 schemes allow to change the number of rounds without loosing backward
 compatibility. I guess bcrypt is a candidate. This new algorithm should
 then be the new default.


Don't know much about bcrypt sorry.

Thanks again for your help, all is now happy