Summary: | net-mail/fetchmail - heimdal compatibility | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Hammer (RETIRED) <mueli> |
Component: | New packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | matthias.andree |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 185899 | ||
Attachments: |
fetchmail-6.3.8-r3 which works with heimdal instead of mit-krb5
fetchmail-6.3.8-r3 which works with heimdal instead of mit-krb5 needed patch for ebuild once again a minor change -> "|| die" if the conf.d and the init.d file are missing |
Description
Michael Hammer (RETIRED)
2008-07-10 10:12:13 UTC
Created attachment 160027 [details]
fetchmail-6.3.8-r3 which works with heimdal instead of mit-krb5
Created attachment 160067 [details]
fetchmail-6.3.8-r3 which works with heimdal instead of mit-krb5
Created attachment 160068 [details, diff]
needed patch for ebuild
As I already asked in the older bug: does anyone now what was the purpose of that check, if it seems to work without it ? I myself didn't ran into that problem. Mastamind found this issue - the only difference we found is his --as-needed ld flag. I think a problem only occurs then - my be it's only a linker problem ... I don't know. As far as I can say removing the libs doesn't make any probs because there are no unresolved symbols. I don't really know if that was the point of your question. I also don't know which earlier bug you mean. Can you provide a bug number? g, mueli Well, I was talking about bug 185652. And the point was that this check was probably added for a reason, so I was asking if removing that check is really safe (it may be, if it was something that was affecting only some old lib configs or atypical OSes. Created attachment 160204 [details]
once again a minor change -> "|| die" if the conf.d and the init.d file are missing
Any progress here? We need this one as it blocks heimdal-1.2.x getting into tree ... please have a look on it! g, mueli Hi, As the fetchmail upstream maintainer, I'd suggest to forward such "does anyone know" kind of questions to the fetchmail mailing lists, such as fetchmail-devel@ - we're open to distributor input, comments, concerns, questions, remarks. Thank you. I'm adding myself to Cc: and hope to address this bug for fetchmail 6.3.12. I want to add fetchmail-6.3.12 now. Michael, your latest attached ebuild still uses krb4 in src_configure but dropped it from DEPEND. This seems to be wrong. Do we remove krb4 completely? | -IUSE="ssl nls kerberos krb4 hesiod tk" | +IUSE="ssl nls kerberos hesiod tk" [...] | - kerberos? ( app-crypt/mit-krb5 ) | - krb4? ( <app-crypt/mit-krb5-1.7[krb4] ) | + kerberos? ( virtual/krb5 ) [...] | - $(use_with krb4 kerberos) \ krb4 support should be completely removed. krb4 isn't secure and will be dropped sooner or later (more sooner than later ;) ) by upstream. I've to be honest - it's a long time gone since I last worked on this fetchmail issue. If configure is searching for krb4 it would be nice if we can "disable" it - if possible. g, Michael If the question is whether fetchmail will automatically pick up Kerberos 4: it will not automatically include it. The configure default is --without-kerberos. So krb4 was removed in 6.3.13 and it depends on "kerberos? ( virtual/krb5 )". heimdal is probably not useable until openssl has heimdal support too (#245934)? Thanks (In reply to comment #13) > So krb4 was removed in 6.3.13 and it depends on "kerberos? ( virtual/krb5 )". Not upstream, but fetchmail isn't picking up Kerberos IV unless that's explicitly requested. Note I haven't tested this in a long time. > heimdal is probably not useable until openssl has heimdal support too > (#245934)? Fetchmail supports GSSAPI-with-Kerberos5 for authentication with Kerberos tickets (i. e. you fetch the ticket-granting-ticket (TGT) with kinit or thereabouts and can then authenticate). I don't see why OpenSSL would need Kerberos support in this situation. |