Re: Failed: apache/httpd#484 (2.4.42 - 5ad7f90)
On Thu, Mar 19, 2020 at 08:32:25AM -0700, Mike Rumph wrote:
> Build #484 fails on test #484.13, Linux Ubuntu, Regenerate ap_expr
> +./buildconf --with-apr=/usr/bin/apr-1-config --with-regen-expr
> unknown option --with-regen-expr
> The command "./test/travis run_${TRAVIS_OS_NAME}.sh" exited with 1.
It's something screwy with the conditional on the test, which should not
run for 2.4.x and is described as:
- if: branch != 2.4.x
name: Linux Ubuntu, Regenerate ap_expr
but this build is special because it's a tag. Could adjust those tests
to be "if: branch = master" but then that's wrong when we branch 2.5.x.
Not obvious how to fix it right now.
Anyway, ignore the failure, everything else passed and it's good ;)
Re: Failed: apache/httpd#484 (2.4.42 - 5ad7f90)
Build #484 fails on test #484.13, Linux Ubuntu, Regenerate ap_expr
+./buildconf --with-apr=/usr/bin/apr-1-config --with-regen-expr
unknown option --with-regen-expr
The command "./test/travis run_${TRAVIS_OS_NAME}.sh" exited with 1.
On Thu, Mar 19, 2020 at 8:12 AM Travis CI wrote:
> apache
>
> /
>
> httpd
>
>
>
> [image: branch icon]2.4.42
> [image: build has failed]
> Build #484 failed
>
> [image: arrow to build time]
> [image: clock icon]9 mins and 41 secs
>
> [image: Daniel Ruggeri avatar]Daniel Ruggeri
> 5ad7f90 CHANGESET →
>
> Tag HEAD of 2.4.x as 2.4.42
>
> git-svn-id:
> https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.42@1875426
> 13f79535-47bb-0310-9956-ffa450edef68
>
> Want to know about upcoming build environment updates?
>
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you!
> SIGN UP HERE
>
> [image: book icon]
>
> Documentation
> from build emails from the apache/httpd repository.
> To unsubscribe from *all* build emails, please update your settings
> .
>
> [image: black and white travis ci logo]
>
> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: cont...@travis-ci.com | Amtsgericht Charlottenburg,
> Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz:
> DE282002648
>
Re: [VOTE] Release httpd-2.4.42
On Thu, Mar 19, 2020 at 10:45 AM Daniel Ruggeri wrote: > > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.42: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz > sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed > *httpd-2.4.42.tar.gz > sha512: > 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837 > *httpd-2.4.42.tar.gz > > The SVN tag is '2.4.42' at r1875427. > Looks like r1874288 broke my basic apxs usage w/o DESTDIR in use. Seems broken in my trunk sandbox too.
Failed: apache/httpd#484 (2.4.42 - 5ad7f90)
Build Update for apache/httpd - Build: #484 Status: Failed Duration: 9 mins and 41 secs Commit: 5ad7f90 (2.4.42) Author: Daniel Ruggeri Message: Tag HEAD of 2.4.x as 2.4.42 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.42@1875426 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/httpd/commit/5ad7f90dc6f4 View the full build log and details: https://travis-ci.org/github/apache/httpd/builds/664423610?utm_medium=notification_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
[VOTE] Release httpd-2.4.42
Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.42: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: 2e4505796dfaebcceab6ba22e5fa221e07ad488e *httpd-2.4.42.tar.gz sha256: cbac6f8211744a74f798db792b74da9f6fb5a4fbee94234cf2b01aeb9ffe57ed *httpd-2.4.42.tar.gz sha512: 09d0f3bd9266907eea91ac9129a3c41658929b9fd88d627c1fccceaf952548d2c3ad62099b9bcd1ae4822402c1dbda90b8bfb9f64cd5eac9f84ed249faffb837 *httpd-2.4.42.tar.gz The SVN tag is '2.4.42' at r1875427. -- Daniel Ruggeri
Re: [Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP
On 19 Mar 2020, at 02:40, Eric Covener mailto:cove...@gmail.com>> wrote:
> Neat, have you thought about mod_auth_form in relation to this?
> Something on my wishlist has been to not put the password in the
> session / not continue to call the original auth provider.
Yes - the two modules that will benefit from token support are mod_session
(which mod_auth_form is just one possible “onramp” to obtain a session token),
and mod_ssl, where the token is the cert.
There is the addition of the (non backportable, but optional and we can leave
it out of the backport) check_user() provider function, which allows a user in
token to be checked if they still exist. The token being verified as valid is
the “password”, leaving just the request to verify whether the user exists.
This lets us remove the “the password is set to ‘password’” hack on mod_ssl,
that makes life difficult if you want to support certs and passwords during a
transition period, or certs for mobile apps and passwords for the web.
typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
* if we can validate this user/password combination.
*
* Use with AUTHN_PROVIDER_VERSION / AUTHN_PROVIDER_VERSION1 providers.
*/
authn_status (*check_password)(request_rec *r, const char *user,
const char *password);
/* Given a user and realm, expected to return AUTH_USER_FOUND if we
* can find a md5 hash of 'user:realm:password'
*
* Use with AUTHN_PROVIDER_VERSION / AUTHN_PROVIDER_VERSION1 providers.
*/
authn_status (*get_realm_hash)(request_rec *r, const char *user,
const char *realm, char **rethash);
/* Given a username, expected to return AUTH_GRANTED
* if we can validate this user exists.
*/
authn_status (*check_user)(request_rec *r, const char *user);
} authn_provider;
The main problem being solved (and the thing that kicked all of this off) was
that one of the Atlassian products said “we no longer support AJP” which was
being used to make certs work. We went “eek” and all of this became a thing.
Regards,
Graham
—
smime.p7s
Description: S/MIME cryptographic signature
