Custom Query (196 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (172 - 174 of 196)

Ticket Resolution Summary Owner Reporter
#56 fixed Disable global SSLUserName kludge andersk
Description

SSLUserName is an evil kludge in our global configuration that interferes with mod_auth_optional, complicates debugging of authentication problems, and cannot be disabled on a per-user basis once enabled globally. We need to get rid of it.

To quote from the scripts-commits@ thread on this issue:

andersk (r409 commit):

Remove SSLUserName, because mod_auth_sslcert is better and having the wrong REMOTE_USER set is confusing.

presbrey:

Its fine if you want to change that behavior from now on but you should certainly leave the old setting for everyone else who quite possibly depend on the old format of the value in the code of their scripts. This is a common issue with global configs.

andersk:

I had done a quick survey of the way REMOTE_USER was used on our vhosts, and didn't notice any obvious problems. We have always been telling users to use SSL_CLIENT_S_DN_Email, anyway, and the fact that REMOTE_USER happened to contain the same value was undocumented. Obviously I can't check every use and there could be new problems, but they will be reported and quickly solved, just like when various PHP extensions were disabled.

(This highlights the need for a good way to inform our users of configuration changes. Is scripts-announce still a useful list to send them to?)

Now that we have more powerful Apache modules for SSL authentication, the SSLUserName hack only gets in the way. For example, with mod_auth_sslcert's AuthSSLCertStripSuffix enabled along with AuthOptional?, I believe that a user with a valid certificate that doesn't match the suffix will still get the REMOTE_USER left over from SSLUserName even though they shouldn't. It's also a pain for debugging that the only side effects of authentication not being properly set up are a @MIT.EDU appended to REMOTE_USER, and mysterious failures when you try to use Apache-level authorization.

I see that you went and reverted my change on the two servers, without making an svn commit. It's fine to let changes lie around uncommited for a little while, but please send email when you do so. Unless you can point to something specific that broke, I'm going to redisable SSLUserName some time tomorrow.

presbrey:

Removing the SSLUserName directive results in a blank REMOTE_USER variable for anyone who hasn't set "AuthType? SSLCert" even when "SSLVerifyClient require" is set.

Surveying the vhosts doesn't quit do it. This change affects everyone on the scripts and scripts-cert hosts as well.

quentin:

I know I'm using REMOTE_USER on one of my sites; rather, I'm using Trac's default handling of REMOTE_USER.

andersk:

But that's part of my point--the scripts server shouldn't be authenticating visitors to scripts that didn't explicitly ask for it. If Trac honors REMOTE_USER by default, then it should be up to the owner to say what a user is, not our global configuration.

Note that, although you can specify SSLUserName in .htaccess if you know you want it, there is no way to _unset_ it if you don't!

quentin:

I don't think it's a good idea to make a non-backwards-compatible change to the way we handle it.

andersk:

I was not aware that people were depending on this broken behavior, so I agree that the change should probably be handled a bit more carefully. Do you think it would be sufficient for this to be part of a mail to scripts-announce, or do you have other suggestions for alerting users?

Regardless of how users are notified, temporarily breaking some scripts that were written with bad assumptions is inevitable. But I think the impact here will be minimal and I'm willing to deal with a few extra support requests.

quentin:

Can I still achieve the same results by configuring mod_auth_sslcert? I don't want authz, just authn.

andersk:

There are plenty of options:

  • You can always set SSLUserName SSL_CLIENT_S_DN_Email in .htaccess.
  • Or, with the normal
    AuthType SSLCert
    Require valid-user
    
    you'll get REMOTE_USER=quentin.
    • If you don't want to forbid visitors without certificates, add
      AuthSSLCertAuthoritative off
      AuthOptional on
      
    • If you need the REMOTE_USER=quentin@… format, add
      AuthSSLCertStripSuffix ''
      
  • Alternatively, you can use SSL_CLIENT_S_DN_Email directly instead of assuming that REMOTE_USER will be the same thing.
#381 fixed Disable allow_weak_crypto on scripts andersk
Description

Now that OpenAFS is fixed, none of our servers should need allow_weak_crypto. We should disable it everywhere.

We may need to contact users that use kinit on scripts, which at the time of this writing, is likely to be approximated by

[andersk@whole-enchilada]:~$ ls /tmp/krb5cc_* -l
-rw------- 1 freeculture freeculture 1145 Jul 24 03:17 /tmp/krb5cc_536886288
-rw------- 1 pony        pony         735 Jul 26 18:02 /tmp/krb5cc_536890340
-rw------- 1 afarrell    afarrell     697 Jul 20 18:56 /tmp/krb5cc_537865110
-rw------- 1 gdb         gdb          695 Jul 26 00:00 /tmp/krb5cc_537883327
-rw------- 1 joeyhkim    joeyhkim    1595 Jul 14 00:00 /tmp/krb5cc_538023618
-rw------- 1 ezyang      ezyang      1127 Jul 26 17:59 /tmp/krb5cc_ezyang_extra
#359 fixed Deprecate Rails 2.3 in Fedora 19 achernya
Description

We've been keeping along a compatibility gem for the transitionary period. It's dead and gone, stop installing it.

Note: See TracQuery for help on using queries.