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

[Cantor, Scott]

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 at some point 
later this summer.

> The following vulnerability was published for xml-security-c.

It is not a vulnerability, and should never have been published as one. It's a 
default that people don't like. I don't like a lot of defaults in lots of 
software but that doesn't make them vulnerabilities.

> NOTE: the supplier disputes this CVE Record on the grounds
> that they are | implementing the specification "correctly"
> and are not "at fault."

Yes, because those are the facts. The scare quotes are unnecessary, as is the 
entire CVE.

> Not sure what to make out of this?  It seems the use of xml
>-security-sec within Shibboleth continues to be supported,
> but otherwise the library is deemed deprecated, so maybe
> this should at least be made explicit in the package
> description?

The mess around this invalid CVE led to my finally putting my foot down and 
demanding that we either retire the code or somebody else show up to help 
maintain it. Nobody did, so the Apache project retired that version of the 
library.

The Shbboleth Project has forked the codebase for its own use since we were the 
only maintainers. It is effectively in the same state in terms of support as 
the xmltooling and opensaml libraries: they're for the Shibboleth SP's use and 
any other uses are not relevant to the maintainers of the code and bugs or 
requests that do not impact the SP will not be prioritized.

Our needs are far less general than the original library's, so taking it over 
allows us to potentially do new releases that strip out a lot of code and 
attack surface, and to make different decisions in regard to API compatibility 
than could be made when it was a general-purpose tool.

The code was only recently converted to git and we are still in the process of 
getting it in place and deciding what to do with it. I have no idea how the 
retirement is going to be managed from the Apache side. Something needs to be 
done with the wiki, etc., but none of that has been determined.

Once the code is fully in place, I was planning to drop a note to the Debian 
packaging list for Shibboleth to note the change, as if the packaging 
continues, it should likely pull from our copy rather than the old one.

I don't have an opinion really about what to do with the package. I'm not about 
to rename it because that's more work for me, not less. I could understand the 
feeling on the Debian side being different about the need to delineate the 
transition and retire the original package since it's unmaintained.

-- Scott

Bug#1007740: curl breaks xmltooling autopkgtest

[Cantor, Scott]

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 failing, so that seems 
likely. The macport is on 7.82 so I can't easily check this quickly, but this 
seems a pretty safe bet. Thanks for saving me more time.

-- Scott

Bug#1007740: curl breaks xmltooling autopkgtest

[Cantor, Scott]

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. It would help 
to determine if this broke in conjunction with openssl revving to 3.0.2 as well.

-- Scott

Bug#1007740: curl breaks xmltooling autopkgtest

[Cantor, Scott]

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 Encrypt rollover, which is what 
test.shibboleth.net uses, and that's what those tests are hitting.

-- Scott

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

[Cantor, Scott]

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:

 feedqueue_t& q = m_feedQueues[application.getHash()];

There were other problems contributing but they wouldn't have been as 
noticeable without that mistake. The code as it is now is basically what should 
be used. But if you're not planning to backport it, it doesn't really matter.
 
-- Scott

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

[Cantor, Scott]

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

[Cantor, 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
> uncover bugs lower in the stack.

Finding the SP is probably fine, but both the SP and that library had a lot of 
very difficult to test changes to the autoconf handling around GSS-API, and 
that's where your problems will probably crop up.

-- Scott

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

[Cantor, Scott]

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

[Cantor, Scott]

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

Summer probably. 

-- Scott

Bug#881857: add CVE

[Cantor, 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 the SP (2.6.1).  Shall I
> wait for the transition to finish before uploading them?

Sorry if I'm misinterpreting, but is this a source level issue or just a 
question of ABI/build decision? SP 2.6.0/etc. definitely should build against 
Xerces 3.2, and probably many older SP versions would also. But if you're just 
referring to what they were built with in Debian packaging cases to date, 
disregard.

-- Scott

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

[Cantor, Scott]

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 Santuario/xml-sec patches that 
I'm also stuck making happen, though that should get released probably next 
month as xml-security 2.0. The scope of the patches are such that I definitely 
advised them not to try it themselves, and I think they took that advice.

-- Scott

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

[Cantor, Scott]

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 time frame on it beyond that. I doubt it will be 
June, but I also doubt it will be January.

-- Scott

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

[Cantor, Scott]

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 related issues in the 
Shibboleth issue tracker, I don't have a specific issue number at hand right 
this second.

I believe there are a number of issues around changes to that code, some other 
changes in the SP to deal with the Apache permission issues, etc.

At this point if you can use syslog you can probably avoid a lot of this mess 
since native.log doesn't really get used much anyway, and another key is to 
make sure the logger setting in shibboleth2.xml isn't set and it's not trying 
to reload logging configuration.

This trace also suggests prefork is being used, which should never be used with 
mod_shib, that's a DOS attack waiting to happen.

-- Scott

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

[Cantor, Scott]

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 just provide a libcurl for both OpenSSL 
versions, with appropriate naming changes?

-- Scott
 

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

[Cantor, Scott]

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, because the
>latest upstream release doesn't support it yet.  Have we got any option
>left to ship Shibboleth in stretch after all?

I'm pretty sure I expressed disbelief that Debian was going to move to 1.1 this 
quickly when I got wind of it, and that there was no chance we (the Shibboleth 
Project) would be able to support it that quickly.

-- Scott

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

[Cantor, Scott]

> 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 libcurl as a netaccessor, that can 
link in openssl and impact mod_shib. Otherwise, not generally.

-- Scott

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

[Cantor, Scott]

> 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's a real problem. The only correct number is going to depend 
on your configuration.

-- Scott

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

[Cantor, Scott]

> 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 making sure they know 
they have to stop relying on aggregates.

-- Scott

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

[Cantor, Scott]

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 split off somehow eventually into a FastCGI package,
but I'll deal with that later.)

Was going to mention that, ok.

Some things that I'm not sure about:

* Should the *.so files stay in the Apache package, or move to something
  else?  Does it make sense to put them in the -utils package along with
  shibd?  Or do they need to go into some other package of their own?
  (They can't go into the library package directly because they aren't
  versioned; presumably the ABI doesn't change between library releases?

They're not linked to, they're plugin extension libraries that are
specific to the ABI of the surrounding libraries they're built against.
Nothing would ever link against them. They really belong with the library
package, or if not, then in one or more extension packages representing
the features they include.

The ODBC plugin is the only thing that requires ODBC, for example, same
for memcache.

  Or if it does, I should move them to a directory versioned by ABI
  version and then include them with the library package.)

These files don't really have an ABI themselves, any more than Apache
modules do, that's why I grouped them together.

* Does it make sense to folks to have all the utilities including shibd
  collected together in shibboleth-sp2-utils?  This would include
  shib-metagen, resolvertest, mdquery, and shib-keygen along with shibd.
  I kind of don't like having daemons in a -utils package, but I think
  splitting things further just creates a ton of packages for no
  particular purpose.

All of the utilities are fine together, but I can't really say for sure
what to do with shibd. Based on what you're saying, it probably really is
its own package if it can't be with the libraries, and the Apache package
should depend on it. It's very unlike those utilities, none of which are
in any way required to run all this.

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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
handle the upgrades.  I'm not sure it's worth it, but if the schemas are
really pointless outside of the use in the libshibsp6 library, maybe I
should do that so that eventually we can drop that package.

On Red Hat I separated the schemas so that multiple versions of the
libraries didn't conflict, but putting them together with the
configuration files probably makes a certain sense. I don't think it's
essential.

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 package depend on it.  Does that make sense?

Yes, probably so. I would say runtime is a pretty good description. But is
it acceptable to have the library package depend on this when there are
files in it that in turn are linked to the libraries? That seems circular.

Yeah, so having the library package depend on them needlessly pulls in
those shared libraries.  But I'm not sure further splitting is worth it to
avoid a few dependencies.  Debian tends to generate a lot of dependencies
on shared libraries and not worry about that too much.

That's fine, just noting it.

I kind of hate to add three more packages, but I think those all make
coherent sense, and in the long run its only an addition of two packages.
And that resolves the FastCGI program problem as well.

That looks good to me.

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 are needed specifically, they're plugin modules to my
runtime, same as Apache modules are to Apache's. Nothing in the core code
depends on them, and I don't believe any default features use them.

I'm inclined to call it libshibsp-plugins, if that sounds like it makes
sense, parallel to the -dev package.

That's what they are, so yes.

Hm, and maybe I should go with
libshibsp-runtime as well instead of shibboleth-sp2-runtime.  Are the
configuration files and schemata only used by the library, or do other
things, like the Apache modules, FastCGI programs, and shibd, use them
directly?

It's gray, but I guess ultimately it's the library using them, the rest of
the pieces are just initializing the library to do work. I suppose I can't
think of any specific way in which the other pieces rely directly on those
files.

Thanks for all your advice on this!

Thank you for all the effort on the project's behalf.

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 them in Debian.  If I break them off into a separate
package, I need to make sure that you either can't get mismatches (the
plugins for libshibsp5 installed but libshibsp6 installed) or that the
plugins are part of the library packages themselves.  The latter would be
my preference, but the current problem with *that* is that the plugins are
in /usr/lib/$arch/shibboleth directly.  If I put that into the library
packages, that means libshibsp5 and libshibsp6 can't be installed
simultaneously, which Debian requires so that it's possible to upgrade
shared libraries without undue pain.

Yeah, I get it, and yes, they are linked directly to specific ABIs. If the
ABI changes, that's when the SONAME changes on libshibsp or the others.

The intent is that they're part of Shibboleth proper, rather than part of
the library package, in the sense that two versions of libshibsp should
work side by side but two versions of the SP as a whole don't.

The location was derived from the Red Hat convention for Apache modules,
which I'm not defending, just explaining. The file system standards don't
really address plugins that I'm aware of.

Does that make sense?  And if so, would it be easy for me to move the
plugins to such a directory in some way?  I'd need to make sure that the
library knew where to load them from, of course.  It's not immediately
obvious to me how, although I'm guessing it's related to SHIBSP_LIBDIR.

Yeah it is, so I suppose there's probably a way to get that into the build
such that each updated build would have a version-specific location to
auto-resolve plugins from. I don't test that all very much, similarly to
how building Kerberos in non-default ways makes for an interesting
experience.

On Red Hat, the files are part of the main binary package that doesn't
support side-by-side installation.

Would it be possible to have a shibboleth-sp2-something package for
shibd and those plugins that would be one version at a time?

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 is Apache-specific except the apache.config examples. The HTML
templates are probably specific to the web server use case, though not to
Apache per se. I doubt any of it is really worth breaking out except for
those config examples.

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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?  (Or, I guess, to be more precise, you don't
want the apache2-api-20120211 dependency, since the extra files in
libapache2-mod-shib2 are harmless.)

Do you want shibd?

I would prefer that shibd be included, because it is possible in theory if
not necessarily in current fact to configure the use of things like
Moonshot and SAML-EC to use shibd in some cases.

In other respects, yes, the code in Moonshot is linked to the SP libraries
but isn't necessarily using the Apache module.

The configuration files obviously can't go into libshibsp5 (see Debian
Policy 8.2), so I need to understand the use case better to figure out how
to properly split the packages up.  I know that shibd can be run on a
separate host from the Apache module, but this isn't currently supported
by the package breakdown.  Maybe this is a similar sort of case?

Probably would be similar in make up, but not for that purpose.

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 provided)?  I was assuming that it was meaningful to use
the library without it, but I never really investigated that assumption.

Strictly speaking it's not an absolute, but the default/only
implementation of the configuration layer of the library does depend on
the XML-based mechanism to do that. Where it lives is arbitrary, but the
use of etc/shibboleth is compiled in as a default.

It sounds like the latter more accurately reflects the real underlying
dependencies and requirements.

I think that's true.

I am a little worried about downgrading
the shibd dependency in libapache2-mod-shib2 to recommends; maybe it
should stay as depends for now even though it's possible to run shibd on a
different host?

I think you can leave that, particularly if all that's installing is shibd
+ init script. It's possible, but ultimately impractical to run shibd
remotely at any scale, leads to security mistakes, and it's an explicit
requirement of the Apache half that a shibd be used, which leads me to
believe requiring it is the best choice.

-- Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 some cases lacking in stability. I 
never reviewed any of that code after I got stuck with it, and it's not in 
great shape. FWIW.

-- Scott

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 don't think that the new module requires any new
APIs present in 2.5 to get it built, but I can't swear to that.

-- Scott




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

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 configuration is not fully compatible.

I know that this work is currently in progress upstream, but I don't yet
know what the ETA is for a new release that will build with Apache 2.4.

An official release will be sometime this summer, but the timing depends
on completing substantial new work on the Windows installer, and we're not
going to ship until that work is done, barring a security problem that
necessitiates shipping. Apache 2.4 support will not be a motivating factor.

The 2.4 module support is minimally tested at this stage and is best
described as experimental, but it should build and minimally works. It
probably could be backported if somebody wanted to.

-- Scott




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Cantor, Scott]

 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
 in the 1.0 API and doesn't exist in 0.44, so you'll probably have to add
 some configure glue to build with the new version.  :/  (Or drop support
 for older versions, of course.)

RH6 has libmemcached now, but it's 0.31, so I can't drop it. Could you please 
attach your downstream patch to this bug?

https://issues.shibboleth.net/jira/browse/SSPCPP-420

-- Scott




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#656656: Please enabled hardened build flags

[Cantor, Scott]

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 being passed to the compiler:

Not that it's necessarily likely here, but with the --silent flag on to
limit noise, you actually can't tell what the actual compiler command is.
There are libtool bugs, usually on Solaris one finds, that break the use
of some flags. I guess it's possible something like that could be
happening.

Is this whole set of options portable? If they're legal on any gcc, I'm
fine adding them to the default flag set for it. If it's highly variable,
not so much.

-- Scott




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org