> Apologies, this was second hand information and probably incorrect.
I think this referred to the 3.3.1 RPM package provided by shibboleth.net.
FWIW I think the relevant upstream commit is
https://urldefense.com/v3/__https://git.shibboleth.net/view/?p=cpp-opensaml.git;a=commit;h=22a610b322e217
> Apologies, this was second hand information and probably
> incorrect. I think this referred to the 3.3.1 RPM package
> provided by shibboleth.net.
That is correct.
> FWIW I think the relevant upstream commit is
Also correct. It probably applies to most older versions, but probably less
cleanl
TL;DR,
This is not a vulnerability, it's a default that people don't like that
required a minor update to change, and that wasn't going to happen. The code
has been formally retired at Apache and forked for the Shibboleth Project's
use, and there will be some form of official indication of that
On 3/15/22, 8:08 PM, "Daniel Stenberg" wrote:
>This is probably the same issue as Bug #1007739. Triggered by a bug in
> curl
>for CN-only certificates:
Ah, probably is. This vhost does use a self-signed cert with a CN only, not
Let's Encrypt, and I can't think why else it would be fai
I would speculate that this isn't caused by curl, but by openssl bumping. I
reproduced the test failure on a Mac, and the change log for openssl 3.0.2
includes a very suspicious incompatible change to a critical function. I need
to dig into it, and I don't know when that will be at this point. I
Looking more closely, I'm going to hope curl is at fault and that this is
actually "just" a CA list issue.
It's very unusual for any of this code to rely on "default" trust store
handling but I'm wondering if this code is tripping on that for some reason. If
so, it's likely due to the Let's Enc
On 3/31/19, 10:44 AM, "Ferenc Wagner,,, on behalf of wf...@niif.hu"
wrote:
> However, I'm somewhat confused about the fix: [1] says it's a "one character
> fix", but d2e6d712 is a
> little more elaborate. How do these fit together?
The bulk of the problem was a missing ampersand in this line
Those are discovery feed cache files, and yes, it's fixed in V3, it was a
regression that got fixed and rebroken a couple of times. It's an easy fix to
backport if need be.
-- Scott
On 12/1/18, 4:48 AM, "Pkg-shibboleth-devel on behalf of wf...@niif.hu"
wrote:
> Please let me know if you need any help; for example I can see that
> version 3 of the resolver uses pkg-config for finding the SP, which is
> cool in principle but nobody tested it in Debian yet, so that may
> uncov
The resolver library upstream has already been updated to reflect all these
necessary changes so you're just duplicating that work.
-- Scott
> Scott, have you perhaps got a new estimate for the timing of the 3.0 release?
Summer probably.
-- Scott
On 11/17/17, 11:48 AM, "Pkg-shibboleth-devel on behalf of Ferenc Wágner"
wrote:
> Now, this is still ongoing:
> https://release.debian.org/transitions/html/auto-xerces-c.html
> The upstream fixes for this issue appeared as new patch level releases
> for XMLTooling (1.6.2), OpenSAML (2.6.1) and t
On 10/30/17, 4:49 PM, "Sam Hartman" wrote:
> My understanding is that the patches already exist, but effort didn't
> exist within Debian to do a good job of taking those patches ourselves
> at least the last time this was discussed on the list.
They're also up and down the stack and includes San
On 10/30/17, 4:36 PM, "Pkg-shibboleth-devel on behalf of Sam Hartman"
wrote:
> So, in order to have a moonshot-gss-eap that builds against openssl 1.1,
> we'll need to get xmltooling fixed.
The version of Shibboleth that supports 1.1 will be out some time next year,
and I can't put much of a t
On 3/24/17, 9:29 AM, "Pkg-shibboleth-devel on behalf of Ferenc Wágner"
wrote:
> This looks like a log4shib threading problem, probably inherited from log4cpp.
More a "the design of the library just doesn't work for these kinds of process
lifecycles" problem, there are issues open on I suspect
On 12/4/16, 4:00 PM, "Ferenc Wagner,,, on behalf of Ferenc Wágner"
wrote:
> Sure you did, and nobody blames you (I hope my mail didn't come through
> like that).
No, it didn't.
Didn't Debian at one time support simultaneous installation of libcurl built on
both NSS and OpenSSL? Can't they jus
On 12/4/16, 11:09 AM, "Pkg-shibboleth-devel on behalf of Ferenc Wágner"
wrote:
> I can't see any conclusion in the OpenSSL 1.1 thread on debian-devel,
>but we're running out of time. We can't keep XMLTooling at OpenSSL 1.0,
>because libcurl uses 1.1, but we can't switch to 1.1 either, b
> It's worth noting that Apache also requires OpenSSL 1.0, which may also
> affect what the Shibboleth stack can link against.
No, that code is isolated into shibd, mod_shib doesn't link to it. That was
deliberate of course, for exactly this reason.
There are edge cases. If you link Xerces to li
> I transform this into a request to enlarge the default shibd start
> timeout. Scott, can you think of any reasonable maximum?
I think you can set it as high as you like, it won't change the startup time
because the code uses the notify API. But setting it too high means not
noticing if there'
> I have been able to reproduce this now. Two minutes seems to be the
> requirement.
That would imply a fairly slow machine + a fairly large metadata source. In any
event, the only real fix is moving to on-demand metadata, so whatever your
metadata source is, you need to be thinking in terms of
On 3/16/14, 11:50 PM, "Russ Allbery" wrote:
>
>If the plugins that come with Shibboleth 2.4 (libshibsp5, IIRC) are not
>guaranteed to work with Shibboleth 2.5 (libshibsp6), then the way they're
>packaged right now only works because they're with the only client that
>can currently use them in Debi
On 3/16/14, 11:03 PM, "Russ Allbery" wrote:
>
>Oh, are they linked to the libraries? Oh, sure enough. Okay, those have
>to go into a separate package then. Are they needed by shibd? I know
>they're needed by the Apache module, so it should depend on the plugin
>package.
None of them are neede
On 3/16/14, 10:31 PM, "Russ Allbery" wrote:
>
>Hm, okay, in that case I'm inclined to change the -common package to
>-runtime (which is a more typical convention for arch-dependent supporting
>files for libraries), put both the configuration and the plugins in that,
>and have the library package d
On 3/16/14, 6:01 PM, "Russ Allbery" wrote:
>Russ Allbery writes:
>
>> shibboleth-sp2-common (new package)
>> /etc/shibboleth
>
>Oh, and also, I could move the contents of shibboleth-sp2-schemas into
>this package as well, but it would require a transitional package to
>handle the upgrades.
On 3/16/14, 5:48 PM, "Russ Allbery" wrote:
>libshibsp6 would depend on shibboleth-sp2-common. libapache2-mod-shib2
>would depend on shibboleth-sp2-utils. Every other package would retain
>its current contents and dependency structure. (I know the authorizer and
>responder need to be split off
On 3/3/14, 4:56 PM, "Russ Allbery" wrote:
>Am I correct in my understanding of the original bug report that the
>shibsp library actually requires /etc/shibboleth to work? In other words,
>from a package perspective, should libshibsp depend on the configuration
>files (however provided)? I was a
On 3/3/14, 4:27 PM, "Russ Allbery" wrote:
>
>Could you explain a bit more about what the use case is? I think I
>understand, but I'm not sure. You're using libshibsp5, and you want the
>standard configuration files, but you aren't using Apache so you don't
>want libapache2-mod-shib2? (Or, I gue
On 3/3/14, 10:01 AM, "Sam Hartman" wrote:
>Russ,
>I'm happy to implement whatever solution is decided for this.
>However it would be good to get discussion on how to approach separating
>the aspects from /etc/shibboleth that are apache-specific from those
>that are not.
None of it is Apache-spec
On Jul 25, 2012, at 10:15 PM, "Russ Allbery" wrote:
> Ah, I had missed that the package installed binaries. (Maybe that's new
> from when I originally packaged it?)
My original RPM didn't. I didn't realize they were useful myself until
recently, but they are fairly sloppy and in some cases lac
On 5/6/12 11:37 PM, "Russ Allbery" wrote:
>
>Ah, okay. It sounds like I (or someone on the Debian side at least) may
>have to look at doing that, since I think Debian's Apache 2.4 and freeze
>schedule make waiting for a summer release somewhat problematic.
Putting me on the spot, I don't think t
>
>As noted in the automated analysis, shibboleth-sp2 uses ap_requires, and
>specifically used the ability to parse the entire list of requires
>directives. It therefore needs substantial upstream redesign (and I
>believe also will requiring dropping at least one feature).
Not dropping, but the c
> Scott, in the long run it looks like you can merge the _ERRNO case with
> the case below it when doing error reporting and remove the SYSTEM ERROR
> or Problems part of the suffix, since memcached_last_error_message() will
> add all that stuff for you. Unfortunately, though, that function is new
On 1/27/12 12:28 PM, "Russ Allbery" wrote:
>
>Hm. Well, the xmltooling build system is straightforward Autoconf and
>Automake, and I'm really at a loss as to what the build system could
>possibly be doing that would cause this. You can see from the build log
>that the right flag is being passed
33 matches
Mail list logo
