Bug#1007740: curl breaks xmltooling autopkgtest

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

Bug#1007740: curl breaks xmltooling autopkgtest

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.

Bug#1007740: curl breaks xmltooling autopkgtest

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

Bug#925978: shibboleth-sp2-common: fills up the /var/cache directory with incommon-metadata.xml.XXXX

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

Bug#925978: shibboleth-sp2-common: fills up the /var/cache directory with incommon-metadata.xml.XXXX

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

Bug#915007: opensaml2 FTBFS with xmltooling 3

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 >

Bug#915044: shibboleth-resolver FTBFS with new log4shib/xmltooling/shibboleth-sp stack

The resolver library upstream has already been updated to reflect all these necessary changes so you're just duplicating that work. -- Scott

Bug#859829: bump

> Scott, have you perhaps got a new estimate for the timing of the 3.0 release? Summer probably. -- Scott

Bug#881857: add CVE

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

Bug#848680: Bug#859831: moonshot-gss-eap cannot migrate to openssl 1.1.0 prior to xmltooling

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

Bug#848680: Bug#859831: moonshot-gss-eap cannot migrate to openssl 1.1.0 prior to xmltooling

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.

Bug#858417: libapache2-mod-shib2: Lots of apache workers in "Closing connection" state. Endless sleeping of apache workers.

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

Bug#844263: libxml-security-c-dev: depending on libssl1.0-dev breaks open-vm-tools

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

Bug#844263: libxml-security-c-dev: depending on libssl1.0-dev breaks open-vm-tools

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

Bug#844263: libxml-security-c-dev: depending on libssl1.0-dev breaks open-vm-tools

> 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

Bug#840056: shibboleth-sp2-utils: upgrade attempt of shibboleth-sp2-utils gets hung at restart of shibd service

> 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

Bug#840056: shibboleth-sp2-utils: upgrade attempt of shibboleth-sp2-utils gets hung at restart of shibd service

> 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

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/16/14, 5:48 PM, Russ Allbery r...@debian.org 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

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/16/14, 6:01 PM, Russ Allbery r...@debian.org wrote: Russ Allbery r...@debian.org 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

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/16/14, 10:31 PM, Russ Allbery r...@debian.org 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

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/16/14, 11:03 PM, Russ Allbery r...@debian.org 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

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/16/14, 11:50 PM, Russ Allbery r...@debian.org 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

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/3/14, 10:01 AM, Sam Hartman hartm...@debian.org 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

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/3/14, 4:27 PM, Russ Allbery r...@debian.org 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?

Bug#740603: /etc/shibboleth not created when not using libapache2-mod-shib2

On 3/3/14, 4:56 PM, Russ Allbery r...@debian.org 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

Bug#682830: xml-security-c packages are missing binary utilties

On Jul 25, 2012, at 10:15 PM, Russ Allbery r...@debian.org 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

Bug#666804: Test rebuild of your package shibboleth-sp2

On 5/6/12 11:37 PM, Russ Allbery r...@debian.org 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

Bug#666804: Test rebuild of your package shibboleth-sp2

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

Bug#658408: libapache2-mod-shib2: FTBFS with libmemcached-dev-1.0.3-1

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

Bug#656656: Please enabled hardened build flags

On 1/27/12 12:28 PM, Russ Allbery r...@debian.org 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