Re: announce mails
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
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?
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
well well if its not BANNED USER Reindl harrold using a ghost account On Tue, Apr 3, 2018 at 5:02 AM, li...@rhsoft.netwrote: > > > 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)
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 Haraldwrote: > > 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
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 Covenerwrote: > > 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
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 Ylavicwrote: > 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
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
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)
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
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
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
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
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
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