The current version of rt-mailgate(1) relies on a specific
	“backdoor” to access the REST interface of RT, like:

    <Location /rt/REST/1.0/NoAuth>
        Order allow,deny
        Allow from ::1 127.0.0.0/8
        Satisfy any
    </Location>

	However, this configuration is insecure in at least two
	situations:

	• the RT installation is on a different host, so that the IP
	  address may be spoofed;

	• the host is used for Shell accounts of some less trusted
	  folks.

	OTOH, given that the HTTP basic authentication is only a matter
	of calling the LWP::UserAgent's ->credentials () method (as per
	the documentation [1]), it doesn't seem like a big deal to have
	it supported.

[1] http://search.cpan.org/~gaas/libwww-perl-5.837/lib/LWP/UserAgent.pm

I thought about forwarding this straight into the upstream bugtracker,
but it might be worth you raising this on rt-users first. If it's simple
as you suggest, and you have a desire for it, then it might be a case of
arguing the point by submission of a suitable patch :)

Best wishes,
Dominic.

[…]

 >> OTOH, given that the HTTP basic authentication is only a matter
 >> of calling the LWP::UserAgent's ->credentials () method (as per
 >> the documentation [1]), it doesn't seem like a big deal to have
 >> it supported.

 > I thought about forwarding this straight into the upstream
 > bugtracker, but it might be worth you raising this on rt-users first.
 > If it's simple as you suggest, and you have a desire for it, then it
 > might be a case of arguing the point by submission of a suitable
 > patch :)

	ACK.

	Actually, I've found that there's liblwp-authen-negotiate-perl,
	which would've the problem solved for me, given that I run
	Apache with mod_auth_kerb enabled anyway.  Yet, that Perl module
	assumes the “user's” way of authentication (kinit), not the one
	that's apt for a service (keytab.)

	Hence, I may consider patching liblwp-authen-negotiate-perl
	instead to support krb5_get_init_creds_keytab ().  (It'd still
	be necessary to patch rt-mailgate to specify the principal to be
	used, though.)

	Still, having some common HTTP authentication schemes supported
	may be a nice addition.  (Though I'm not sure that anything else
	looks as simple as calling ->credentials ().)

Dear submitter,

as the package request-tracker4 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1134418

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)