Bug#866712: moonshot-gss-eap FTBFS on arm64: libeap/src/utils/common.h:429:0: error: "__bitwise" redefined [-Werror]

I'm starting the process of updating to new upstream. I think that is reasonably likely to fix this. If not, I'll look into the issue after the update. I'm OK if moonshot-gss-eap falls out of testing for a few weeks. --Sam

Bug#869260: CVE-2017-11368

I can absolutely prepare a stable point update request for stretch. Is there still going to be a last point release to jessie? If so I'll look into that too; I'd definitely like to get an update in.

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

I'll remove it in purge.; there's another bug open effectively for that. However, I think it is generally a good thing if the file exists. Because of the dpkg bug we no longer install it, but I think our users are better served by leaving the file on upgrades.

Bug#869260: CVE-2017-11368

Take a look at the stretch branch of git://git.debian.org/git/pkg-k5-afs/debian-krb5-2013.git Shall I upload that to stable-security?

Bug#869260: CVE-2017-11368

Actually, on that note, why does this bug merit a DSA? It like the other bugs is a simple KDC crash from an authenticated attacker. It seems like it should be handled the same.

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

=== Resolution === The Technical Committee recognises that circumstances change in ways that make previous resolutions no longer appropriate. In 2012, it was resolved that the nodejs package should not provide /usr/bin/node due to the historical conflict with the ax25-node

Bug#766298: An update on trust router and release status

> "Petter" == Petter Reinholdtsen writes: >> I think shortly after the release of buster, we can close this >> bug and let moonshot-trust-router migrate into testing. Petter> Did this time arrive? Mostly. I'm working through all the moonshot software and

Bug#872760: asterisk-opus: uninstallable in unstable

Package: asterisk-opus Version: 13.7+20161113-3 Severity: grave Justification: renders package unusable The asterisk package in unstable provides asterisk-1fb7f5c06d7a2052e38d021b3d8ca151 but asterisk-opus depends on asterisk-fa819827cbff2ea35341af5458859233 It looks like this is a system that

Bug#863260: kstart: k5start does not recognize network changes

I wonder if your nss stack is somehow caching something about the network and the name servers and that kstart process is no longer able to resolve KDCs. It would be interesting to set KRB5_TRACE to a file, run kstart such that it is failing and see what specifically is not working. My bet is on

Bug#862051: Refer #862051 to ctte

> "David" == David Bremner writes: David> Philip Hands writes: >> I presume we'd want to continue providing /usr/bin/nodejs for >> people that have switched to using that, so that might as well >> continue to be the name of the binary,

Bug#836127: Call for Votes for new TC member

===BEGIN The Technical Committee recommends that Niko Tyni be appointed by the Debian Project Leader to the Technical Committee. N: Recommend to Appoint Niko Tyni F: Further Discussion ===END I vote N>F signature.asc Description: PGP signature

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

control: severity -1 normal Will remove this file early in buster.

Bug#861218: libgssapi-krb5-2: soname-independent files in shared library package (policy 8.2)

> "Helmut" == Helmut Grohne writes: Helmut> Package: libgssapi-krb5-2 Version: 1.15-1 Severity: serious Helmut> libgssapi-krb5-2 is a shared library package and contains Helmut> /etc/gss/mech.d/README. The latter filename does not depend Helmut> on the

Bug#828441: moonshot-trust-router: FTBFS with openssl 1.1.0

There's a new upstream for moonshot-trust-router that I believe should work with openssl 1.1. Realistically, I should be able to deal with moonshot-gss-eap #848680 within a month. I think it may be more like two months to deal with both moonshot-gss-eap and moonshot-trust-router, both of which

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Didier" == Didier 'OdyX' Raboud writes: Didier> For good reasons, Debian forcibly introduced a special-case Didier> when Node.js first appeared in a stable release through only Didier> shipping it under /usr/bin/nodejs. That forced hundreds of Didier>

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Thorsten" == Thorsten Glaser writes: Thorsten> Hi, >> * Restore /usr/bin/node following CTTE #862051 Let's try to drop >> /usr/bin/nodejs before buster. Replaces and Conflicts >> nodejs-legacy. Closes: #754462. Thorsten> please do NOT completely

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

OK, let's give the security team some context. RFC 2744 specifies some kind of unfortunate behavior for error handling. gss_init_sec_context and gss_accept_sec_context have an in/out context parameter (pointer to pointer). You initialize the pointed to value to null the first time through. It

Bug#876927: moonshot-ui FTBFS with vala 0.36

I suspect the version in experimental with work with vala 0.36, but will confirm that.

Bug#872760: asterisk-opus: uninstallable in unstable

OK, if the checksum doesn't change regularly, I can understand why the current arrangement makes sense. It would bxe great to get asterisk-opus rebuilt though:-)

Bug#872056: jessie-pu: package krb5/1.12.1+dfsg-19+deb8u2

I just uploaded the jessie update after fixing the extra comma in the changelog. I did run tests covering these security updates. I found that some of the tests included in make check were already failing on jessie and were still failing after this update. It looks like this may be related to

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

Wait... Is that actually even legal under RFC 1964? Doesn't this lead to leaks for correctly written applications? --Sam

Bug#873563: CVE-2017-11462 -- automatic sec context deletion could lead to double-free

Ah, looked at the commit. Yeah. This makes sense. This is somewhat of a behavior change. Do we want to just bring this into unstable, or do we want to backport it to stable releases? It seems like there is a possibility of problems in either direction.

Bug#862051: [Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Julien" == Julien Puydt writes: Julien> Hi, Le 31/08/2017 à 13:52, Jérémy Lal a écrit : >> How about printing a "nice" warning explaining it would be a good >> idea to move to /usr/bin/node ? Then in next next release drop >> the nodejs symlink.

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Dominique" == Dominique Dumont writes: Dominique> On Thursday, 31 August 2017 13:58:23 CEST Thorsten Glaser wrote: >> > How about printing a "nice" warning explaining it would be a >> good idea to > move to /usr/bin/node ? >> >> That will break

Bug#829671: Custom real addition doesn't seem to work

Hi. d-i preseeding. I'd be happy to work with you if we can remove that from the equation. I'd also be interested in why DNS srv lookups aren't good enough for you. If I had krb5-config to do again, I probably wouldn't support adding realms at all. The goals of krb5-config may not be entirely

Bug#877024: modemmanager should ask before messing with serial ports

Hi. It looks like there hasn't been much traffic on this issue in the last couple of weeks. My analysis is that the key technical point here is whether it's acceptable to treat unknown devices as possible modems. It sounds like: 1) We don't have a good white list of modems. 2) We don't have

Bug#877024: modemmanager should ask before messing with serial ports

> "Aleksander" == Aleksander Morgado writes: >> In going forward, I think it is important to consider that >> Modemmanager's needs and Debian's needs may be different here. >> In the case of Modemmanager as an upstream project, it may be >> desirable

Bug#877024: Modemmanager probing of unknown Devices

Hi. In #877024, the TC was asked to rule on whether modemmanager should continue to probe USB devices that might not be modems. There's been significant involvement from upstream leading to a new optional behavior that is less aggressive about probing unknown devices. Would it help the

Bug#881597: krb5-multidev: Please make the package multi-arch installable

Unfortunately, krb5-config is used fairly widely by software not in Debian. In the past krb5 has been fairly conservative, which in this case would mean having krb5-multidev depend on krb5-multidev-bin for a release. If we did that we would have a solution for buster+1 to make krb5-multidev m-a

Bug#882867: krb5-kdc: cannot write to default log location

Hi. When I install krb5-kdc, it logs to syslog not to /var/log/krb5kdc.log. Where in the files installed by the krb5-kdc package are you seeing configuration to install to /var/log/krb5kdc.log. I agree upstream configures (or in some cases recommends configuring) things that way, but I'm not

Bug#881597: krb5-multidev: Please make the package multi-arch installable

As you can tell I did not get around to looking at this last weekend. The US holiday ended up taking up more time than I anticipated, and then I got sick. This week my day job is taking up all my time; hope to have some Debian cycles next week. --Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

So, I'm uncomfortable making a long-term promise to support krb5-config in a multi-arch environment. Today, the multi-arch change is easy to work with. However, it seems entirely reasonable that the recommended cppflags and cflags might differ between architectures, and I don't know that I want

Bug#881597: krb5-multidev: Please make the package multi-arch installable

Thanks. I'll take a look next week. This looks very promising. Unless I'm missing something, I think you've done a lot of the work regardless of whether we want to wrap krb5-config architecture scripts or wrap a script that calls cross-pkg-config. Why do you want to replace krb5-config with

Bug#881597: krb5-multidev: Please make the package multi-arch installable

> "Russ" == Russ Allbery writes: >> But how can we link this output to CC? Russ> That's a trickier question, since I'm not sure Autoconf or Russ> make alway exports the current compiler as the CC environment Russ> variable in all the ways krb5-config is

Bug#881597: krb5-multidev: Please make the package multi-arch installable

control: tags -1 -patch control: severity -1 wishlist > "Russ" == Russ Allbery writes: Russ> Hugh McMaster writes: >> The packages krb5-multidev and libkrb5-dev are not multi-arch >> installable. >> A diff of the i386 and amd64

Bug#881597: krb5-multidev: Please make the package multi-arch installable

So, I finally got a chance to look at this. It sounds like you're taking a significantly different approach than we had discussed earlier. What we had talked about is parsing the output of $CC. For example asking gcc what tripple it was built for and going from there. But what you did is assume

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

control: affects -1 moonshot-gss-eap control: block -2 with -1 Hi. I will shortly be uploading a version of moonshot-gss-eap that is happy to build against either openssl 1.1 or openssl 1.0. Unfortunately, it won't actually build against openssl 1.1 because dependencies on libxmltooling-dev will

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

>>>>> "Cantor," == Cantor, Scott <canto...@osu.edu> writes: Cantor,> On 10/30/17, 4:36 PM, "Pkg-shibboleth-devel on behalf of Cantor,> Sam Hartman" Cantor,> <pkg-shibboleth-devel-bounces+cantor.2=osu@lists.alioth.debian.org

Bug#877024: Modemmanager probing of unknown Devices

Like Ian, I honestly don't know what the rules are in this situation. Wou/ld it be reasonable for him to make an NMU to experimental, and then if there is no objection after testing to unstable? In parallel, it seems desirable to see if any of the maintainers are active. --Sam

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

>>>>> "Benjamin" == Benjamin Kaduk <ka...@mit.edu> writes: Benjamin> On Mon, May 07, 2018 at 05:10:27PM +0100, Ben Hutchings wrote: >> On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote: >> >> There are basically thre

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

I'm returning from vacation and jumping into the middle of this. Back in the day when I wrote the code that became k5_get_os_entropy we viewed two cases: * kadmind. There we're likely to sometimes be generating long-term shared secrets, and it seemed like strong random numbers were

Bug#766194: debhelper: dh_installinit should gain option to ignore start failures

> "Niels" == Niels Thykier writes: control: tags -1 -moreinfo (I hope this supplies the info you need; obviously retag if you have more questions.) Niels> Hi Sam, Niels> Thanks for the bug report. Niels> It sounds like you rather want krb5-kdc not to start

Bug#877024: Modemmanager probing of unknown Devices

Dear Ian: I wanted to make you aware of a status update. The maintainer who has been doing most of the uploads on modemmanager stepped down after receiving my query. First, I'd like to extend my thanks to Michael for his hard work on modemmanager in the past and all the things he continues to

Bug#871698: upstream patch

I think that until the upstream release we could just increase the length and get a fair distance.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

Hi. I like the approach of making krb5-config not dynamic, but I'd prefer to discover the behavior of the compiler rather than to base our interactions on its filename. My plan is to use the following: CC=${CC-cc} tripple=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//'

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

> "Adrian" == Adrian Bunk writes: Adrian> On Tue, Jan 09, 2018 at 01:23:32PM +0100, Guillem Jover wrote: >> ... Given the background of build-profiles, I'm very much in >> favor of introducing the equivalent usage as Gentoo USE flags, >> which was its main

Bug#881597: krb5-multidev: Please make the package multi-arch installable

>>>>> "Hugh" == Hugh McMaster <hugh.mcmas...@outlook.com> writes: Hugh> Hi Sam, Apologies for the delay in replying. Somehow your Hugh> message landed in my spam folder. Hugh> On Friday, 5 January 2018 1:44 PM, Sam Hartman wrote: >&g

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

> "Adrian" == Adrian Bunk writes: Adrian> For many use flags the only benefit is an unused library Adrian> less on the system when the flag is disabled, and this also Adrian> applies to the proposed nosystemd profile discussed in this Adrian> bug. Agreed.

Bug#887810: krb5-multidev: "krb5-config.mit --cflags gssapi" returns wrong include directory

I am testing a fix. My apologies for the sloppy change.

Bug#777579: Database ends up in wrong location if krb5.conf an kdc.conf differ

Thanks for your additional information. I think we have a good understanding of how this bug happens in the case where kdc.conf and krb5.conf have conflicting realm information or where kdc.conf does not supply the realm that the KDC is actually serving. My recommendation is that we look into

Bug#829671: Can we start depending on /etc/krb5.conf.d

Hi. A while back krb5-config received a request to support /etc/krb5.conf.d especially for custom realm configuration that requires more than just DNS. It looks like the Heimdal in unstable supports krb5.conf including a config directory. How would you feel about turning this on in the

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

As a FYI, I did some experiments with kvm, and I do seem to have enough entropy to get the KDC started there. I have not played with Xen recently. It's a bit harder to set that up, and I'm unsurprised that might be more tricky to get randomness with than kvm.

Bug#819017: Prod

My last query on this issue proposed a way forward: installing a conffile. I never received a reply. If I have not received a reply by the next time I triage bugs, I'll close this.

Bug#829749: Is there a better way to handle Kerberos ldap configuration

Hi. Mostly for the slapd maintainer. Currently krb5-kdc-ldap ships an OpenLDAP schema file for the Kerberos schema. I just noticed that we don't ship the ldif file for the newer format slapd config and will be fixing that in my next upload. Currently in order to take advantage of either, the

Bug#777579: Retitling

control: retitle -1 Database ends up in wrong location if krb5.conf an kdc.conf differ control: severity -1 normal control: tags -1 -moreinfo I reread the long bug log. We were never able to reproduce the user's problem. However, the closest we were able to get is that if krb5.conf and

Bug#829749: Is there a better way to handle Kerberos ldap configuration

>>>>> "Ryan" == Ryan Tandy writes: Ryan> Hi Sam, Ryan> On Mon, Jul 16, 2018 at 05:02:34PM -0400, Sam Hartman wrote: >> Mostly for the slapd maintainer. Currently krb5-kdc-ldap ships >> an OpenLDAP schema file for the Kerberos schema

Bug#829671: Can we start depending on /etc/krb5.conf.d

>>>>> "Brian" == Brian May writes: Brian> Sam Hartman writes: >> A while back krb5-config received a request to support >> /etc/krb5.conf.d especially for custom realm configuration that >> requires more than just DNS. &g

Bug#863260: kstart, systemd and dns

control: tags -1 help Apologies for the long delay. It looks like the problem here is in fact DNS. It sounds like the k5start process cannot look up the IP of the KDC even after the network comes back. Other processes like dig function, but those processes are not making periodic requests of

Bug#829749: Is there a better way to handle Kerberos ldap configuration

> "Ryan" == Ryan Tandy writes: Ryan> I had not, actually. Assuming our default slapd configuration, Ryan> adding a schema is just: Ryan> ldapadd -H ldapi:// -Y EXTERNAL -f /path/to/schema.ldif Ah, looking back at my notes, you're right. Adding the schema was easy. The hard

Bug#887937: krb5-user: Should krb5-user depend on/recommend krb5-k5tls?

I think we should add a recommends or suggests relationship. I'm reluctant to add a hard dependency. There are two issues. The first is that it pulls in code for people who don't need it; that's minor. The second issue is that krb5-k5tls is GPL-incompatible at least as we build it because it

Bug#892593: [PATCH] libverto: FTCBFS / Please add a pkg.libverto.noglib build profile

this approach seems a bit strange. Why would we want a package specific build profile rather than excluding glib from a stage1 build of libverto. Also, note that I'm about to update to a new version of libverto and start building for libevent. I wonder if for bootstrapping we want to pick one

Bug#892593: [PATCH] libverto: FTCBFS / Please add a pkg.libverto.noglib build profile

So, in general, I think picking a single event backend should be fine. Most applications work with all event backends; krb5 certainly does. I'm fairly uncomfortable with the idea of using an extension package namespace here though because it seems like you'll need to break this cycle on every

Bug#911481: libkrb5support0:i386 has broken dependencies

control: tags -1 moreinfo control: severity -1 normal Hi. Your bug is a little short on details, and I was not able to reproduce. I took a new sid chroot, added i386 as an architecture, and installed libkrb5support0:i386 by apt install libkrb5support0:i386 I ended up with krb5 1.16.1-1 and

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

Actually directly switching on vendor seems fairly bad. However, to the extent that downstream changes can be encapsulated into options/deltas that someone might want, I think it may often be reasonable to carry the delta in Debian. So imagine that Ubuntu and several other downstreams care more

Bug#904558: What should happen when maintscripts fail to restart a service

> "Ian" == Ian Jackson writes: Ian> * If the maintainer has no particular reason to diverge the Ian> right answer is usually to fail the postinst with init systems Ian> that do not provide service supervision; but to not fail the Ian> postinst with ones that do. (I think

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

>>>>> "Wouter" == Wouter Verhelst writes: Wouter> On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote: >> That said, even there there are tradeoffs. As an example, Ubuntu >> tries to use unmodified Debian source packages wher

Bug#904558: What should happen when maintscripts fail to restart a service

> "Simon" == Simon McVittie writes: Simon> the error path is most important were packages that provide a Simon> system-level API to other packages, so their failures are Simon> likely to cause other packages to fail to configure (such as Simon> local DNS caches and

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

> "Wouter" == Wouter Verhelst writes: Wouter> But in the general case, I feel that downstream packaging Wouter> changes belong downstream, not in Debian; therefore it is Wouter> best to recommend that, in the general case, packages in Wouter> Debian do not switch on

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

> "Adrian" == Adrian Bunk writes: latest upgrade of libkrb5-3 (1.16.1-1 -> 1.16.2-1) >> automount starts but dies immediately after accessing a >> automounter point. >> >> Automount is configured to authenticate via GSSAPI using system >> keytab. After the GSSAPI

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

I'd value the autofs configuration much more than the directory setup instructions. I have no desire to go install centos7 to debug a Debian bug:-) and have some familiarity with setting up LDAP. What I don't have is familiarity configuring autofs.

Bug#919427: emacspeak eterm does not speak several key commands

package: emacspeak severity: important tags: patch version: 47.0+dfsg-6 Hi. several of the key eterm commands don't speak. I'm opening a bug that I already have a patch for; expect a merge request shortly.

Bug#877469: NMU diff for 1.0.23-3.1

, because that is an arch +all package with no ABI dependencies. We don't want shared library +dependencies on an arch all package because it breaks the ability to +do binary NMUs for library transitions, Closes: #877469 + + -- Sam Hartman Tue, 11 Dec 2018 08:50:44 -0500 + node

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

>>>>> "Sebastian" == Sebastian Andrzej Siewior writes: Sebastian> On 2018-12-11 18:26:24 [-0500], Sam Hartman wrote: >> Fixing moonshot-gss-eap and getting a new moonshot-ui is next up >> for me for Debian weekend tasks. Sebastian> This

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

Fixing moonshot-gss-eap and getting a new moonshot-ui is next up for me for Debian weekend tasks.

Bug#916699: Run minissdpd debconf question insufficiently detailed for an advanced user to answer it

package: minissdpd version: 1.5.20180223-3 Hi. Minissdpd got pulled in on an upgrade from stretch to buster by something--I haven't bothered to check why. I have my debconf priority set to medium and I got asked whether I wanted to start minissdpd automatically. That's fine: I asked for more

Bug#915007: opensaml2 FTBFS with xmltooling 3

Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file the removal requests. They are both basically broken in unstable, so there's no reason to block.

Bug#915007: opensaml2 FTBFS with xmltooling 3

Built fine I have not yet tested against moonshot On December 3, 2018 8:52:10 AM EST, "Cantor, Scott" wrote: >On 12/1/18, 4:48 AM, "Pkg-shibboleth-devel on behalf of wf...@niif.hu" >on behalf of wf...@niif.hu> wrote: > >> Please let me know if you need any help; for example I can see that >>

Bug#916047: csound: regression in String handling

package: csound version: 1:6.12.2~dfsg-1 severity: important justification: Regression over stretch with insidious and hard-to-diagnose consequences I noticed that my orchestras were failing on several sound files after upgrading to buster, and tracked it down to some cases of filenames being

Bug#916066: csound regression: zir opcode appears entirely broken; hangs instrument

package: csound version: 1:6.12.2~dfsg-1 I was experiencing strange failures with orchestras with csound 6.12 and eventually I've tracked it down to the zir opcode to read a value from zk-space at i-time. It's fairly basic: the zir.csd from the csound examples fails to print out anything in the

Bug#915639: Apologies for shibboleth-resolver FTBFS

Hi. I am not sure how I managed to produce the binary package for amd64. I *thought* that I used sbuild in a clean sid chroot to do so, but it's quite clear from trying to reproduce that that I failed. I'm somewhat baffled because my work flow makes it hard for something not coming out of

Bug#867945: Working on porting to libsecret

I'm working on porting moonshot-ui from gnome-keyring to libsecret. It's somewhat involved because upstream needs to support both interfaces--they have a long tail of operating systems they need to work on. Also, the existing code could use some refactoring to be cleaner. I'm probably 70% of

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

So what's happening here is that a k5_mutex_lock is getting an invalid argument error calling a series of wrappers that basically all boil down to pthread_mutex_lock. So, basically somehow pthread_mutex_lock is getting passed a bad mutex. This appears to be happening in the credentials cache

Bug#919236: Inappropriately broad default CA for EAP configuration

package: freeradius tags: security version: 3.0.17+dfsg-1 severity: important justification: Inappropriately broad default authorization The debian freeradius package changes the default eap configuration to use the default list of Debian certification authorities as the default CAs for verifying

Bug#919234: ttls fails with tls 1.3, enabled by default

package: freeradius severity: important version: 3.0.17+dfsg-1 justification: regression that totally breaks connectivity tags: upstream I've cc'd Kurt because he requested openssl 1.3 test results a while back. While writing automated tests for moonshot-gss-eap, I discovered that by default

Bug#919234: [Pkg-freeradius-maintainers] Bug#919234: ttls fails with tls 1.3, enabled by default

control: forwarded -1 https://github.com/FreeRADIUS/freeradius-server/issues/2385 I'll try to get a patch for this if we don't hear something interesting from upstream soon. I think I'm in a better position than most in Debian to write such a patch. However I'm fairly busy.

Bug#919236: [Pkg-freeradius-maintainers] Bug#919236: Inappropriately broad default CA for EAP configuration

control: tags -1 help > "Michael" == Michael Stapelberg writes: Michael>Can you send a patch please? It€™s been like Michael> that since before I touched the package. My suspicion is that it's removing parts of a patch. In fact, it looks like most of what's needed is to remove

Bug#924260: NMUDIFF for csound 1:6.12.2~dfsg-3.1

index 84a4831..72a6859 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +csound (1:6.12.2~dfsg-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix diskgrain, syncgrain and syncloop when sample rate of sample +differs from orchestra, Closes: #924260 + + -- Sam

Bug#926477: dgit accepts short keyid even though debsign does not

Package: dgit Version: 8.3 Severity: important Dear Maintainer, Someone wrote in a forum that I can't quote here something along the lines of it should be a bug for any Debian package to accept a short-form GPG keyid. I agree. Dgit still accepts short-form keyids (and it doesn't look like

Bug#870428: libverto1: Upstream has moved

I apologize for dropping the ball on this so long. It looks like there is a 0.3.0 release of verto, which was folded into krb5. However, It looks like there's not an upstream tarball on github for anything past 0.2.6. Because I dropped the ball so much I'm under tight time pressure to get an

Bug#870428: Info received (Bug#870428: libverto1: Upstream has moved)

Sigh. I'm just confused. Got the 0.3.0 tar ball fine.

Bug#870428: libverto1: Upstream has moved

>>>>> "Robbie" == Robbie Harwood writes: Robbie> Sam Hartman writes: >> I apologize for dropping the ball on this so long. It looks like >> there is a 0.3.0 release of verto, which was folded into krb5. >> However, It looks

Bug#922952: ITP: simdjson -- Parsing gigabytes of JSON per second

I don't know about official policy, but I think you could make your bug not RC by detecting whether the current system can support the package in some reasonable wail and failing more gracefully than with SIGILL. It's not a requirement that all packages work on all systems. Open-vm-tools doesn't

Bug#828441: moonshot-trust-router: FTBFS with openssl 1.1.0

Status is that I didn't find the time to get moonshot-trust-router dealt with before buster and so I had deprioritized it. There is in fact a new upstream, and it does fix the issue. Blocking on moonshot-trust-router is silly: no one wants the version in unstable anyway. Is it possible to remove

Bug#924260: Csound: regression in diskgrain stretch->buster when file sr != orchestra sr

package: csound severity: important justification: Stretch regression with no work around without code changes version: 1:6.12.2~dfsg-3 tags: patch, fixed-upstream, upstream Hi. In https://github.com/csound/csound/issues/1119 I reported an issue. In stretch, if you want to deal with a file that

Bug#925242: unblock: csound/1:6.12.2~dfsg-3.1

(1:6.12.2~dfsg-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix diskgrain, syncgrain and syncloop when sample rate of sample +differs from orchestra, Closes: 924260 + + -- Sam Hartman Thu, 21 Mar 2019 10:31:29 -0400 + csound (1:6.12.2~dfsg-3) unstable; urgency=medium

Bug#921458: Handling build-depends-indep for non-x86 source packages

> "Alex" == Alex Bennée writes: Alex> Hi, Alex> The following bug has come up and we would like some input Alex> from the multiarch and cross developers on how best to handle Alex> this case. Alex> In an ideal world all cross compilers would be available on Alex>

Bug#926656: git-debrebase docs are intimidating

I don't know. As I said in my mail I'm not even sure there's a problem here. Let me give a bit of background here. Ian and I had what I thought was a really exciting call about git and source packages and stuff. It sounded like Ian hopes we'll some day get rid of patches-unapplied data models

Bug#905772: libvirtd upgrade broken stretch->buster

control: severity -1 serious justification: libvirtd upgrades from stretch to buster break causing apt to fail and requiring the admin to get the systemd units into a consistent state before things can continue Unfortunately based on discussion so far this is a complex bug to fix. Ubuntu's

Bug#905772: [Pkg-libvirt-maintainers] Bug#905772: libvirtd upgrade broken stretch->buster

Guido let me know if you need any help or prod me on IRC if I'm needed. Will certainly test the result, but if you get stuck would be happy to spend time on this.

Bug#905772: libvirtd upgrade broken stretch->buster

>>>>> "Guido" == Guido Günther writes: Guido> Hi, Guido> On Mon, Apr 15, 2019 at 02:38:27PM -0400, Sam Hartman wrote: >> control: severity -1 serious >> >> justification: libvirtd upgrades from stretch to buster break >

<    4   5   6   7   8   9   10   11   12   13   >