Bug#1074429: xml-security-c: CVE-2024-34580

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

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" <pkg-shibboleth-devel-bounces+cantor.2=osu@lists.alioth.debian.org on behalf of wf...@niif.hu> wrote: > Now, this is still ongoing: > https://release.debian.org/transitions/html/auto-xerces-c.htm

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" <pkg-shibboleth-devel-bounces+cantor.2=osu@lists.alioth.debian.org on behalf of hartm...@debian.org> wrote: > So, in order to have a moonshot-gss-eap that builds against openssl 1.1, > we'll need t

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" <pkg-shibboleth-devel-bounces+cantor.2=osu@lists.alioth.debian.org on behalf of wf...@niif.hu> wrote: > This looks like a log4shib threading problem, probably inherited from log4cpp. More a "t

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" <pkg-shibboleth-devel-bounces+cantor.2=osu@lists.alioth.debian.org on behalf of wf...@niif.hu> wrote: > I can't see any conclusion in the OpenSSL 1.1 thread on debian-devel, >but we're running

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

Bug#602328: libapache2-mod-shib2: apache should be restarted on install/upgrade

We started discussing this in January, but the thread died off without reaching conclusion: http://lists.alioth.debian.org/pipermail/pkg-shibboleth-devel/2010- January/001565.html I doubt we can do anything about this so close to release, but if at all possible, we should. As per the

Bug#586922: When pipewalker is launched, the X server crash and stop

So I install linux-image-2.6.32-5-686, libdrm (2.4.21) and xserver-xorg-video-intel (2.12) packages. And now, when I start pipewalker, the X server restart. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#586922: When pipewalker is launched, the X server crash and stop

Package: pipewalker Version: 0.7.2-1 Severity: grave Tags: squeeze Justification: renders package unusable When I launched the following command : $ pipewalker 2 pipewalker.log the X server crash and the content of the errors file is : -- Start of pipewalker.log

Bug#571631: libapache2-mod-shib2: shib-keygen generates world-readable key file

Don't you think it's kind of an openssl bug to create the key material with full permissions? Shouldn't it creat(keyfile, 0600)? Would be nice I suppose. This aside, I'd recommend working around the issue by creating the key file beforehand with restricted permissions, and not touching

Bug#571631: libapache2-mod-shib2: shib-keygen generates world-readable key file

Note that we can't just use umask 177 in the Debian version of this script since Debian runs shibd as a non-root user and then won't be able to read the certificate. For Debian, we should set the group ownership to the shibd user we create and make the file group-readable. If there's a

Bug#571631: libapache2-mod-shib2: shib-keygen generates world-readable key file

Thank you for the offer! I think it's going to be a bit tricky for you to do something upstream that will also work in Debian without modifications, since you won't be able to rely on the group that we're creating as part of the package installation, so I suspect we should probably carry a

Bug#571631: libapache2-mod-shib2: shib-keygen generates world-readable key file

Actually, I think I was confusing your original umask fix with this submitted patch: https://bugs.internet2.edu/jira/browse/SSPCPP-281 That has a -u option for controlling the user, and I suppose having a group option would make sense also. It would help if folks could collaborate and suggest

Bug#569569: gwibber: Gwibber windows disappears when I click on the tray icon of the notification area

Package: gwibber Version: 1.2.0+bzr358-2 Severity: important I use the gnome desktop and I have 5 virtual desktops. The bug appears when I click on the tray icon applet located in the notification area, and if gwibber is already open in an other virtual desktop : then the gwibber window

Bug#569004: More piece of information

I discover that if I logout from gnome and connect again then icon appears. But they never appears in my first gnome session. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#569004: gnome-applets: Icons of weather applets does not appear in the panel.

hope I was clear, Cantor -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin

Bug#549936: Bug#548126: pu: package opensaml2/2.0-2+lenny1

Faidon Liambotis wrote on 2009-10-08: Yes, I've verified that they work in my setup. As Scott said before, there more than a dozen scenarios (literally!) and I'm not able to test each one of them. However, they work in the couple that I've tried and the fixes are with upstream's (Scott)

Bug#549936: Bug#548126: pu: package opensaml2/2.0-2+lenny1

Florian Weimer wrote on 2009-10-07: OK, will do. How should we handle the fact that the newer xmltooling is breaking the old (as in, lenny) opensaml2/shibboleth-sp2? We could theoretically add a Conflicts: to a new upload of xmltooling, but this is unnecessary. We don't do this for every

Bug#549936: Bug#548126: pu: package opensaml2/2.0-2+lenny1

Faidon Liambotis wrote on 2009-10-07: Scott and Russ, under which conditions did you see the specific opensaml code to be inlined on shibboleth-sp2? The version of opensaml released on the Internet2 site, which is 2.2.1, includes an inline version of the MetadataCredentialCriteria matches

Bug#549936: Bug#548126: pu: package opensaml2/2.0-2+lenny1

Florian Weimer wrote on 2009-10-07: Scott and Russ, under which conditions did you see the specific opensaml code to be inlined on shibboleth-sp2? Does shibboleth-sp2 create invoke a constructor of that class? Do the compiled binaries contain any reference to the vtable? There are numerous

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use=signing are broken

Faidon Liambotis wrote on 2009-10-06: I think the problem is in the following change: * SECURITY: Correctly honor the use attribute of KeyDescriptor SAML metadata to honor restrictions to signing or encryption. This is a partial fix; the complete fix also requires a new version

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use=signing are broken

Russ Allbery wrote on 2009-10-06: Ack, I'm sorry. I didn't realize that, so yes, that will indeed be a problem. Sorry, I didn't understand that the fixes were being published separately, since I was reviewing them simultaneously. As it stands, I see now that the advisory I wrote should make

Bug#532584: libshibsp1: Backchannel fails to contact AA

Russ Allbery wrote on 2009-06-10: http://marc.info/?t=9696307713r=1w=2 seems to point at this error being either a bug in how the OpenSSL routines are called or a bug in the certificate configuration. Since it works for you manually with curl, I suspect there's something different between