Bug#840955: Status of ITP/RFP courier-zdkimfilter
Hello Helge, On 11/1/23 10:18, Helge Kreutzmann wrote: I haven't done anything besides doing a testbuild. Before proceeding further I wanted to inquire about the status of your work on this package, so I don't waste time redoing Debian integration. thanks for reaching out. Unfortunately, I can only tell you that I plan to abandon packaging of courier altogether. It's been a struggle for me to keep up the community work recently and many people were far less than appreciative. Noticing that upstream now runs their own packaging convinced me it's not worth for me to keep maintaining this for Debian proper. Sorry for the rather bad news. Markus
Bug#987009: courier-authlib: the purported fix for #984810 breaks maildrop "delivery mode"
Control: tags -1 + moreinfo On 15.04.21 16:20, Flavio Stanchina wrote: The fix for #984810 breaks maildrop "delivery mode" because maildrop is no longer able to look up user details after dropping privileges (or at least this is what I think is happening, from my understanding of how "delivery mode" works). Hm.. shouldn't the user running maildrop be part of the 'courier' group? I don't think that's sufficient justification for making the information world-readable. Regards Markus
Bug#985705: courier-authlib: upgrades broken due the move of the tools
On 22.03.21 14:10, PICCORO McKAY Lenz wrote: dpkg: error al procesar el archivo /var/cache/apt/archives/courier-authdaemon_0.71.1-2_i386.deb (--unpack): intentando sobreescribir `/usr/sbin/authenumerate', que está también en el paquete courier-authlib 0.71.0-1 dpkg: considerando la desconfiguración de courier-authdaemon, ya que lo rompería la instalación de `courier-base' ... thanks for your report. That surprises me, because I did add: Package: courier-authdaemon ... Replaces: courier-authlib (<< 0.71.1-2~) Breaks: courier-authlib (<< 0.71.1-2~) and 0.71.0-1 clearly is (<< 0.71.1-2~). I'll double check. Regards Markus
Bug#985329: solved upgrading to experimental
Control: tags -1 + moreinfo Control: severity -1 normal On 16.03.21 05:46, PICCORO McKAY Lenz wrote: i have older packages yet in my install, i dont know how happened.. but do not close this bug until i found why happened after check and forces proper upgraded in xperimental.. is working please properly identify the bug you intend to report before filing it as grave, potentially marking the package as unfit for release. Regards Markus
Bug#983478: courier: Please revert the fam -> gamin change for bullseye
On 12.03.21 11:05, Adrian Bunk wrote: On Wed, Mar 03, 2021 at 08:17:39AM +0100, Markus Wanner wrote: do you have any reference here? #966273 still asks for the removal of fam and has no mention of any contradicting release team decision. Nor did I find any reference in the release mailing list (by subject). sorry for the late reply, the discussion was in http://meetbot.debian.net/debian-release/2021/debian-release.2021-02-24-19.00.log.html Alright, thanks for the pointer. This contains very little reasoning, though. (As opposed to the arguments brought up by Glenn.) Given courier-imap had several issues in the past with FAM (see #357769, #578937, #599682), I think it's actually safer to just depend on (and build against) gamin, instead. I certainly run courier-imap on gamin exclusively on my systems. Thus, unless a good reason and a couple of bug fixes pop up, I'd like to leave it this way and not revert the change for courier. Best Regards Markus
Bug#984810: courier-authlib: authtest can access user data information from normal users accoun
Control: tags -1 + confirmed
Control: severity -1 important
On 08.03.21 16:50, PICCORO McKAY Lenz wrote:
Currently as normal user, it can be accessed
to users database if we setup mysql, postgres
or sqlite, inclusively ldap setups.. i mean,
a limited account can query users mail data
to made some kind of attack
This information is reveal from DB:
serveruno:$ authtest test
Authentication succeeded.
Authenticated: test (uid 244, gid 244)
Home Directory: /home/users/intranetusers/test
Maildir: /home/users/intranetusers/test/Maildir
Quota: (none)
Encrypted Password: {MD5RAW}34ca4238a0b923820dcc509a6f75849b
Cleartext Password: 1
Options: (none)
While I generally agree that this is not optimal and should be better
guarded, it does not seem to reveal sensitive information (i.e. it is
not very different from a `cat /etc/passwd`).
Given authtest clearly is a test-tool only, I agree that its permissions
should be limited as requested.
ADDITIONAL NOTE: the package that own the program is authlib.. this
is completely wrong.. cos important setup is not retrieved by
reportbug like the authdaemon setup files modified.. the
/usr/sbin/authenumerate /usr/sbin/authpasswd and /usr/sbin/authtest
must belong to authdaemon (to make sense)
Thanks, that's a good hint as well.
Regards
Markus
Bug#984818: courier-authdaemon init script is not idempotent
Package: courier-authlib Version: 0.71.1-1 The (sysv) init script for courier-authdaemon exits with an error in case of an attempt to start an already started or stop an already stopped service. This clearly breaks the postrm script.
Bug#984694: courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/configurable.
Control: tags -1 + confirmed Hello Simon, On 07.03.21 11:47, Simon Iremonger wrote: On current debian bullseye, courier-mta is not startable, looks like some kind of problem in init scripts (but could be executables/environment), as per system info and console log below. thanks for filing a bug against Courier. I can reproduce at least the postinst error on a SysV-init syntem. Can I ask you to please file a separate report for the postrm failure? Thank you. Best Regards Markus
Bug#981513: Bug#983478: Bug#981513: courier: please replace fam with gamin
On 05.03.21 08:55, Glenn Strauss wrote: Yes, I agree that FAM should be dropped. Markus, I do not understand why you were asked to revert the change from gamin back to FAM. Right. Nor has this request been backed up by evidence of a release team decision. To move things forward, I just uploaded a 1.0.16-2 for courier that builds against libgamin-dev, again. Was #983478 filed before it was clear that remaining packages could convert to use gamin? No, just immediately after the conversion in 1.0.15-1. ==> Markus, I ask that we give Adrian a chance to respond, but I see no good reason to keep courier depending on FAM. On the contrary, using FAM is MORE LIKELY to lead to conflicts with other packages that are using gamin (instead of FAM) I agree. If you see anything wrong with 1.0.16-2, could you please file a new bug report (and avoid cross posting). These two are closed already (and therefore didn't quite properly track the issue). Thank you. Best Regards Markus
Bug#981513: Bug#983478: Bug#981513: courier: please replace fam with gamin
On 03.03.21 09:21, Glenn Strauss wrote: If there is any remaining concern about upgrade compatibility, ..none from my side. Courier would simply depend on gamin only. I don't see why that would cause issues during upgrades. In Bullseye, change the fam package to import the gamin source, and then bump the fam package version number. The fam package would actually be the same as gamin, and upgrades would avoid any packaging system deficiencies in choosing between gamin and fam for upgrade. That sounds very confusing and outright wrong, IMO. What's wrong with just dropping fam? (Whether right now for Bullseye or at any later point in time...) Regards Markus
Bug#981513: Bug#983478: Bug#981513: courier: please replace fam with gamin
On 03.03.21 09:01, Glenn Strauss wrote: I did the research in #510368 and #966273, reviewing the actual code and confidentally concluded that FAM can be removed from Bullseye. Thanks for this research. I read through both issues and don't question the general reasoning. However, I clearly do not want to needlessly change this forth and back, as I already did once. If fam stays in Bullseye, I think it's better to have courier build against libfam-dev. Whether or not fam stays in Bullseye is up to the release team. The safest choice is to have a single library (gamin) used in the distro, rather than having both FAM and gamin. I'm actively using courier built against libfam-dev in combination with gamin. So that's known working as well. Fixing them requires trivial substitutions in debian/control I know, because I already did "fix" this once. Only to be asked to revert the change few days later. I'm not going to repeat that process. Let's have a clear decision, please. And then take action. So far I've read the release team had "decided that fam will stay in bullseye". If that's not true or revisited, I'm happy to adjust courier. Regards Markus
Bug#983478: courier: Please revert the fam -> gamin change for bullseye
Adrian, On 24.02.21 21:29, Adrian Bunk wrote: - the release team has now decided that fam will stay in bullseye, it is expected that fam will be removed for bookworm do you have any reference here? #966273 still asks for the removal of fam and has no mention of any contradicting release team decision. Nor did I find any reference in the release mailing list (by subject). Regards Markus
Bug#983478: Bug#981513: courier: please replace fam with gamin
On 03.03.21 07:02, Glenn Strauss wrote: Please replace "libfam-dev" with "libgamin-dev" in debian/control Also, please replace "gamin | fam" with simply "gamin" for Bullseye. I just changed it forth and back. To change it again, we need some deeper reasoning than just "please do". Are you claiming the initial information given by Adrian Bunk in #983478 (which you're responding to) is wrong? Regards Markus
Bug#981513: courier: please replace fam with gamin
Control: tags -1 + pending On 17.02.21 02:16, Chris Hofstaedtler wrote: Given gamin is currently marked as being autoremoved, could you look into replacing libfam-dev/libgamin-dev with inotify in courier? I have passed on the request to replace fam/gamin with inotify: https://sourceforge.net/p/courier/mailman/message/37221664/ As I hope for gamin to get fixed and stay at least for bullseye, I will adapt courier to build against libgamin-dev. Regards Markus
Bug#981513: courier: please replace fam with gamin
Hello Chris, On 17.02.21 02:16, Chris Hofstaedtler wrote: Given gamin is currently marked as being autoremoved, could you look into replacing libfam-dev/libgamin-dev with inotify in courier? thanks for pinging again. Courier does not currently have any support for inotify, AFAICT. I'll raise this concern upstream. Best Regards Markus
Bug#980881: courier unicode cone lib bugfix
Control: fixed -1 2.1.2-1 Control: found -1 2.1-3 Hi, thanks for filing this bug report. I'm hereby only marking it as not affecting bullseye, which already provides an upstream version with the fix included. Regards Markus
Bug#966808: flightgear: new dependency: qml-module-qtqml
Control: tags -1 +moreinfo Hi, thanks for filing a bug report with the Debian flightgear package. On 8/2/20 5:12 PM, attila wrote: The GUI of the sim requires a new package called qml-module-qtqml, without it the interface/sim is unusable. Please add it as dependency. I suppose you mean the `fgfs --launcher` GUI. Flightgear depends on the following two qml modules already: * qml-module-qtquick-window2 * qml-module-qtquick2 I cannot find a package `qml-module-qtqml` nor can I reproduce the bug. With 2020.3.5+dfsg-1, the launcher seems to work fine for me. Can you provide more details, please? Regards Markus
Bug#979161: webmlm daemon fails cos systemd does not work as old days
Control: tags -1 confirmed Yes, I noticed this as well. Which of these two options do you prefer: * a dialog asking for a first list to create (and default to creating it under e.g. /var/lib/courier-mlm) * install the systemd service as initially disabled, similar to the sysv init scripts Regards Markus -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#979131: courier FTBFS on arch=all
Package: src:courier Version: 1.0.14-1 Severity: important Tags: pending courier fails to build on arch=all, see e.g. on buildd: https://buildd.debian.org/status/fetch.php?pkg=courier=all=1.0.14-1=1609168389 I have prepared a fix, the next upload will include it.
Bug#190725: README's highly confused and wrong configurations
Control: tags -1 +pending Hi, sorry, I mixed this one up with #341205, should have gone here. Please do not cross post to multiple bugs, thank you. On 12/30/20 7:24 PM, PICCORO McKAY Lenz wrote: > bug report #126735 and #341205 : in same topic: default installation is not explained (respect the courier documented) and there's no Debian document that points the difference.. neither a document of debian way and the differences.. ..I'd argue that the error message provided is sub-optimal. First of all, it should arguably be a 403 Forbidden HTTP response code and not assume it's the admin actually reading this. Second, pointing to INSTALL is a bit blunt, given it's a whopping 4k lines to read. (Some of) your additions to README.Debian are good. I'll adjust the error message to point to that file as well. And given it's the www, actually **link** the appropriate section in the installation documentation online. Regards Markus
Bug#341205: README's highly confused and wrong configurations
Control: tags -1 +pending Hi, On 12/30/20 7:24 PM, PICCORO McKAY Lenz wrote: bug report #126735 and #341205 : in same topic: default installation is not explained (respect the courier documented) and there's no Debian document that points the difference.. neither a document of debian way and the differences.. ..I'd argue that the error message provided is sub-optimal. First of all, it should arguably be a 403 Forbidden HTTP response code and not assume it's the admin actually reading this. Second, pointing to INSTALL is a bit blunt, given it's a whopping 4k lines to read. (Some of) your additions to README.Debian are good. I'll adjust the error message to point to that file as well. And given it's the www, actually **link** the appropriate section in the installation documentation online. Regards Markus
Bug#974979: make courier configuration by default on directories.. event files
Control: tags -1 -moreinfo Control: severity -1 wishlist Control: retitle -1 use configuration directories by default On 12/31/20 2:44 PM, PICCORO McKAY Lenz wrote: Currently Courier uses several configuration files in /etc/courier that can be replaced by a subdirectory whose contents are concatenated and treated as a single, consolidated, configuration file. Ah, understood. Thanks for explaining. I'm already using multiple files in a directory in most cases. It seems well possible already, but just a matter of defaults. I agree the directories should be created by default. First setp to solve this is in courier-base package, must be changed to true, this will create the minimal set of directories. If you're speaking of the `courier-base/webadmin-configmode` template question, I'm with you. This needs to vanish. Later in a new revision remove the question and migrate to use only directories (that can co-exist with normal files), manpages of the courier suite points so many times about those directories.. Manpages should be adjusted to clarify both is possible, IMO. by example the esmtpacceptmailfor: can be a single file in the path /etc/courier/esmtpacceptmailfor of a directory at the path /etc/courier/esmtpacceptmailfor.dir and all files inside will be parsed as single one. Yes, works that way. better example is hosted domains, can be a single file in /etc/courier/hosteddomains but is better a directory /etc/courier/hosteddomains and each domain could be a single file (named as the domain without dots) and with domain inside in plain text. I don't necessarily think that's a good approach, but I agree that it should be possible. However, I think it already *is* possible now. It clearly works for me (tm). Anything in specific that doesn't work when configuring using multiple files in a directory? Regards Markus
Bug#893839: sqwebmail fix for cache login and right permissions
On 1/2/21 6:44 AM, PICCORO McKAY Lenz wrote: Jan 1 23:33:53 isomaker sqwebmaild: LOGIN, user=user, ip=[186.91.0.20] Jan 1 23:33:53 isomaker sqwebmaild: maildircache: Cache create failure - unable to create file /var/cache/sqwebmail/223550/us/user. solution seems easy and no security will implicate here: in sqwebmail.postinst line 68: add_override courier bin 0770 /var/cache/sqwebmail and in sqwebmail.prerm line 51: del_override courier bin 0770 /var/cache/sqwebmail Thanks for the diagnostics and providing a patch. This was explained in the pull !9 README.Debian of the courier git work and i will added that patch to the merge request. Please stop extending that single pull request, otherwise I won't ever finish reviewing it and it can't ever get merged. Instead, for future fixes and enhancements, please file individual merge requests. Something like one per bug or topic would be ideal. Regards Markus
Bug#978755: RFH: courier
Package: wnpp Severity: normal I'm looking for people to help with packaging of the Courier MTA suite, including its many components shipped as one suite (and packaged from the same src:courier). I personally use the MTA as well as the IMAP and POP clients, but none of courier-faxmail, courier-ldap, courier-mlm, sqwebmail, or courier-webadmin. Therefore, these are not in a good state and may not work at all. Thanks Markus
Bug#974979: make courier configuration by default on directories.. event files
Control: tags -1 +moreinfo Control: severity -1 normal Hi, from this wording, I have no idea what this bug is about, sorry. Please clarify your proposal. Markus
Bug#584126: pain in ass cos depends on "default-mta"
On 12/27/20 5:56 PM, PICCORO McKAY Lenz wrote: of course those packages can work with other mail suite but default (as just apt-get install does) install doe snot handle that! so dependences are wrong in all way! Relax. It can't be that bad. The bug references version 0.64.2-1 (as of 2012), where courier-imap and courier-pop both depended on: `exim4 | mail-transport-agent`. Nowadays, the dependencies are on `default-mta | mail-transport-agent`, which seems correct given that courier is *not* the default MTA on Debian. Note that as per the popularity contest, many more users use courier-imap (0.44%) than courier-mta (0.02%), meaning that the vast majority of users of courier-imap actually *do* use it with an MTA other than courier. I do not want to annoy that majority of users. Nor am I aware of any significant warning or problem that arises should I try to use courier-imap in combination with courier-mta. Just installing both packages works fine for me. No matter even the order Just install both packages. But yes, if you want a non-default MTA, you need to explicitly say so. That's intended behavior and not to be overridden by courier-imap. And no, Courier is not the default and it is not likely to become in the future, either. > Depends: courier-mta | default-mta | mail-transport-agent This clearly wouldn't change anything in case the default-mta (exim4-daemon-light) is already installed. And would do the wrong thing (install courier-mta rather than the default-mta), if none of the above are installed, already, but the user chose to install only courier-imap, but not courier-mta. Unless a real dependency issue (other than something boiling down to courier-mta not being the default MTA) comes up, I'm inclined to close this ticket. So far, nothing substantial has been shown in this ticket. Regards Markus
Bug#933948: too many split f the same things
On 12/27/20 5:22 PM, PICCORO McKAY Lenz wrote: the review needs registration etc etc.. i try to analize but it has too complicated things for quick review.. It's a gitlab instance used for Debian packaging. Registration is free. For your convenience, I'm attaching the patch. Note that Viktor Szépe has approved the merge request already (thanks a lot for the immediate review, Viktor!). It will be part of the next upload (due soon, to get courier back into Debian testing). it seems has several inter-dependencies.. or as you mantainers called circular dependences.. so i'm unable to check in production cos does not buil in a OBS environment.. I see no circular dependency here. Register to review is a pretty simple one-way dependency. again as i mailed.. more complications.. Glad you begin to understand that packaging is not quite as trivial as compiling from source for just your local installation. Regards Markus diff --git a/debian/changelog b/debian/changelog index 2efb82b..d7070e6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -10,6 +10,8 @@ courier (1.0.14-1) UNRELEASED; urgency=medium * New upstream release 1.0.14. * Make courier-imap depend on fam or gamin. Closes: #578937, #974585. * Refresh patch 0012 + * Improve regular expressions used to parse config files. Allows +single and double quotes. Closes: #933948. * Add patch 0026-correct-config-dir-in-docs.patch to correct paths to certificates in manpages and HTML documentation. Closes: #946591. * Drop patch 0015-Disable-imapscanfail-maildirwatch-error-reporting: diff --git a/debian/courier-imap.courier-imap-ssl.init b/debian/courier-imap.courier-imap-ssl.init index b9ed0b8..1043ebb 100644 --- a/debian/courier-imap.courier-imap-ssl.init +++ b/debian/courier-imap.courier-imap-ssl.init @@ -17,7 +17,7 @@ fi DAEMON="/usr/sbin/imapd-ssl" DESC="Courier IMAP server (TLS)" -DO_START=$(sed -ne 's/^IMAPDSSLSTART=\([^[:space:]]*\)/\1/p' /etc/courier/imapd-ssl | tr "A-Z" "a-z") -PIDFILE=$(sed -ne 's/^SSLPIDFILE=\([^[:space:]]*\)/\1/p' /etc/courier/imapd-ssl) +DO_START=$(sed -ne "s/^IMAPDSSLSTART[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\(\\w*\\)[\\'\\\"]\\?/\\L\\1/p" /etc/courier/imapd-ssl) +PIDFILE=$(sed -ne "s/^SSLPIDFILE[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\([^[:space:]]*\\)[\\'\\\"]\\?/\\1/p" /etc/courier/imapd-ssl) . /usr/lib/courier/init-d-script-courier diff --git a/debian/courier-imap.init b/debian/courier-imap.init index ce2f20e..1217e15 100644 --- a/debian/courier-imap.init +++ b/debian/courier-imap.init @@ -17,7 +17,7 @@ fi DAEMON="/usr/sbin/imapd" DESC="Courier IMAP server" -DO_START=$(sed -ne 's/^IMAPDSTART=\([^[:space:]]*\)/\1/p' /etc/courier/imapd | tr "A-Z" "a-z") -PIDFILE=$(sed -ne 's/^PIDFILE=\([^[:space:]]*\)/\1/p' /etc/courier/imapd) +DO_START=$(sed -ne "s/^IMAPDSTART[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\(\\w*\\)[\\'\\\"]\\?/\\L\\1/p" /etc/courier/imapd) +PIDFILE=$(sed -ne "s/^PIDFILE[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\([^[:space:]]*\\)[\\'\\\"]\\?/\\1/p" /etc/courier/imapd) . /usr/lib/courier/init-d-script-courier diff --git a/debian/courier-mta.courier-msa.init b/debian/courier-mta.courier-msa.init index 5dac698..f283969 100644 --- a/debian/courier-mta.courier-msa.init +++ b/debian/courier-mta.courier-msa.init @@ -17,7 +17,7 @@ fi DAEMON="/usr/sbin/esmtpd-msa" DESC="Courier MSA server" -DO_START=$(sed -ne 's/^ESMTPDSTART=\([^[:space:]]*\)/\1/p' /etc/courier/esmtpd-msa | tr "A-Z" "a-z") -PIDFILE=$(sed -ne 's/^PIDFILE=\([^[:space:]]*\)/\1/p' /etc/courier/esmtpd-msa) +DO_START=$(sed -ne "s/^ESMTPDSTART[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\(\\w*\\)[\\'\\\"]\\?/\\L\\1/p" /etc/courier/esmtpd-msa) +PIDFILE=$(sed -ne "s/^PIDFILE[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\([^[:space:]]*\\)[\\'\\\"]\\?/\\1/p" /etc/courier/esmtpd-msa) . /usr/lib/courier/init-d-script-courier diff --git a/debian/courier-mta.courier-mta-ssl.init b/debian/courier-mta.courier-mta-ssl.init index 9c5eb05..9f0a2da 100644 --- a/debian/courier-mta.courier-mta-ssl.init +++ b/debian/courier-mta.courier-mta-ssl.init @@ -17,7 +17,7 @@ fi DAEMON="/usr/sbin/esmtpd-ssl" DESC="Courier MTA TLS server" -DO_START=$(sed -ne 's/^ESMTPDSSLSTART=\([^[:space:]]*\)/\1/p' /etc/courier/esmtpd-ssl | tr "A-Z" "a-z") -PIDFILE=$(sed -ne 's/^SSLPIDFILE=\([^[:space:]]*\)/\1/p' /etc/courier/esmtpd-ssl) +DO_START=$(sed -ne "s/^ESMTPDSSLSTART[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\(\\w*\\)[\\'\\\"]\\?/\\L\\1/p" /etc/courier/esmtpd-ssl) +PIDFILE=$(sed -ne "s/^SSLPIDFILE[[:space:]]*=[[:space:]]*[\\'\\\"]\\?\\([^[:space:]]*\\)[\\'\\\"]\\?/\\1/p" /etc/courier/esmtpd-ssl) . /usr/lib/courier/init-d-script-courier diff --git a/debian/courier-mta.init b/debian/courier-mta.init index e2bd979..db2781a 100644 --- a/debian/courier-mta.init +++ b/debian/courier-mta.init @@ -17,7 +17,7 @@ fi DAEMON="/usr/sbin/esmtpd" DESC="Courier MTA server" -DO_START=$(sed -ne 's/^ESMTPDSTART=\([^[:space:]]*\)/\1/p' /etc/courier/esmtpd | tr
Bug#933948: Config value incorrectly parsed in init.d script
Control: -1 severity grave Control: -1 tags +pending Hi, On 11/21/20 3:46 PM, Norbert Harrer wrote: > But in /etc/init.d/courier-mta-ssl it is parsed with sed: > > DO_START=$(sed -ne 's/^ESMTPDSSLSTART=\([^[:space:]]*\)/\1/p' > /etc/courier/esmtpd-ssl | tr "A-Z" "a-z") thanks a lot for this fine analysis. I propose to tweak the regular expressions to be more resilient to quotes (single and double) as well as spaces (which deviates from how the shell would interpret it, though). Please review the following merge request: https://salsa.debian.org/debian/courier/-/merge_requests/8 Note 2: Another thing is curious: Not all courier services use the init.d scripts, some have their own systemd config in /lib/systemd/system/ which bypass the init.d script Yeah, this is unfortunate and should be addressed as well. Thanks for pointing it out. Best Regards Markus
Bug#974585: current patch only hides error but still happened
Control: severity -1 important Control: merge -1 578937 Hi, On 11/12/20 3:57 PM, PICCORO McKAY Lenz wrote: as of 0015-Disable-imapscanfail-maildirwatch-error-reporting.patch only hide the error message and seems real solution are by install FAM I agree, but this merely is a duplicate of #578937 with an unjustified severity level. Adjusted. Best Regards Markus
Bug#946591: mkesmtpdcert does not make file where it said (seems solved)
Control: severity -1 minor Control: tags -1 +pending Hi, thanks for this bug report. Indeed, the manpages and other documentation pointed to the wrong path. A fix with a patch 0026-correct-config-dir-in-docs.patch has been committed and will be included in the next upload. In the future, please don't use 'critical' for documentation issues. Thank you. Best Regards Markus
Bug#900761: please separate passwd manipulation from the library package, together with expect et al
On 2/3/19 10:51 PM, Josip Rodin wrote: > If it's an upstream issue that can't be fixed with packaging, then > tag it upstream and forward it, as the fine manual teaches you to. Well, I think of it as a feature, not a bug, so I see no reason to forward anything. Think of authlib as a general abstraction layer over several different ways to manage user accounts. This certainly includes the ability to change a users password. > (I'm not sure why people are so anxious to close bug reports these days...) The former courier maintainer was blamed to have closed issues too quickly without really taking care. I'm trying to avoid that. Can I take that question as an okay to close the issue, then? Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#900761: please separate passwd manipulation from the library package, together with expect et al
Control: -1 tags +wontfix Hello Josip, On 6/4/18 2:16 PM, Josip Rodin wrote: > For some reason there exists an expect script in > /usr/lib/courier/courier-authlib/authsystem.passwd > which seems to be calling passwd(1), > which causes courier-authlib to depend on expect(1), > which in turn has a bunch of other dependencies, > which in turn gets installed on all systems where users want packages > that happen to depend on courier-authlib (regardless of whether those > users actually use the authlib's facilities) the authlib library itself actually provides means to change passwords, using expect in case you're using system accounts (as opposed to some database for example). The recommendation to install expect therefore seems entirely justified. It's not like you cannot remove it or ignore the recommendation. > In my case, the latter is maildrop, which honestly I have no idea whatsoever > how it could ever come into a situation where it would want the > authentication subsystem to invoke a user password change. Ugh.. how else would you change the password, if not via the authentication subsystem? > In fact I'm pretty sure someone would slap us with a critical security bug > if it ever came to pass that a mail filtering utility was even attempting > to manipulate the password of a user for whom it was filtering mail. I agree here. > Please separate this functionality from the library package into a separate > package, which can then depend on and invoke whatever it needs. I fear that's not possible, as it would mean splitting the library itself. Please speak up if you have ideas or wishes on what the packaging could do to improve your use case. Otherwise, I'll close this issue. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#912633: Possible conflict betwwen courier-imap and courier-imap-ssl?
On 1/17/19 4:29 AM, Erik de Castro Lopo wrote: > I have just run into this same issue and its a bit of a pain. This issue as in "No supported cipher suite with the recent switch to TLS 1.3 in OpenSSL 1.1.1"? TBH I didn't check the recently uploaded 1.0.5-1 against this OpenSSL issue. Are you saying that issue clearly persists with the newly uploaded version? > One thing I notivce however is that I have: > > # dpkg -l | grep courier-imap > ii courier-imap 5.0.5+1.0.5-1 amd64 Courier mail server - IMAP > server > ii courier-imap-ssl 4.18.1+0.78.0-2 all Courier mail server - IMAP > over TLS [transitional] I removed courier-imap-ssl, as it's a transitional package in stretch, already. It can be removed safely. Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#912633: courier-imap-ssl: No supported cipher suite with the recent switch to TLS 1.3 in OpenSSL 1.1.1.
Control: reassign -1 courier-imap Soren, thank you for reporting this issue. It's a bit surprising, as courier is compiled against GnuTLS since 0.76.3-2. Maybe there's an equivalent change... I'm preparing an upload of a new release of courier and hope for that to work with newer versions of GnuTLS. As a side note: courier-imap-ssl turned into a transitional package around 0.76.0-1. Nowadays, courier-imap provides all you need. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#879530: courier: contains code related to gnutls pgp supprt
Control: tags +1 pending On 10/22/2017 06:30 PM, Andreas Metzler wrote: > GnuTLS stopped enabling OPENPGP certificates by default in 3.0.2 (Sept > 2011). OpenPGP support in gnutls was removed in 3.6.0. (Noop stub > functions are still shipped to avoid ABI breakage.) > > Therefore imho it makes sense to drop the pgp/gnutls code from courier. thanks a lot for your patch. The next upload will include it. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#872089: courier-mta: TLS_TRUSTCERTS default value
Control: found -1 0.76.3-5 Control: severity -1 normal Hello Viktor, please excuse my late reply to this issue. On 08/14/2017 02:40 PM, Viktor Szépe wrote: > We have a typo - maybe - in four config files: > TLS_TRUSTCERTS=/etc/ssl/cert.pem > The value should be /etc/ssl/certs I can reproduce this. On a fresh install, a grep for TLS_TRUSTCERTS in /etc/courier yields: courierd:TLS_TRUSTCERTS=/etc/ssl/cert.pem esmtpd:TLS_TRUSTCERTS=/etc/ssl/cert.pem esmtpd-ssl:TLS_TRUSTCERTS=/etc/ssl/cert.pem Version 0.78.0-2 shipped in unstable does not show this issue, though. And for a stable release, a change in configuration files certainly doesn't warrant an upload. So I'm going to close this issue. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#881696: courier: Please include /usr/lib/courier/courier/courierfilter in courier-mta
Control: tags -1 +pending Hello Steve, please excuse my late response. On 11/14/2017 08:36 AM, Steve Langasek wrote: > Please find attached a one-liner patch to add the missing file to the> > courier-mta binary package. Thank you for this patch, it will make it into the next upload. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#900517: courier-imap: Doesn't start: imapd/etc/init.d/courier-imap: xrealloc: .././print_cmd.c:1557: cannot allocate 512 bytes (376832 bytes allocated)
Control: tags -1 +unreproducible Control: severity -1 normal Hello Mehdi, please excuse my late response to this issue. On 05/31/2018 07:43 PM, Mehdi Amin wrote: > Starting Courier IMAP server: imapd/etc/init.d/courier-imap: xrealloc: > .././print_cmd.c:1557: cannot allocate 512 bytes (376832 bytes allocated) There is no file `print_cmd.c` in the sources of courier. Nor could I reproduce this issue on oldstable. Instead, `print_cmd.c` can be found in bash and has the following at line 1557: > the_printed_command = (char *)xrealloc (the_printed_command, > the_printed_command_size); Therefore I think this is unrelated to courier-imap. Please provide further details, if you continue to have trouble with bash or courier-imap. Otherwise, I'd like to close this issue. Thank you. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#822683: maildrop: removal of courier-maildrop changed the behaviour
On 09/15/2018 08:14 AM, Zhao Difei wrote: > It's been more than 2 years without resolution. I'm sure a lot of mail > server maintainers are using local package. Resolve this bug seems > trival to me, maybe just re-add the courier-maildrop package? Please check all the bugs closed by the removal of courier-maildrop. It's certainly not as simple as that. Kind Regards Markus Wanner
Bug#908169: libasio-dev: Asio on Linux stalls in epoll
Shane, On 09/06/2018 11:42 PM, Shane Loretz wrote: > The version of libasio-dev in sid can deadlock if used in multiple threads. thank you for the heads-up, I'll have a look shortly. Kind Regards Markus Wanner
Bug#899813: fgrun: Invalid maintainer address pkg-fgfs-c...@lists.alioth.debian.org
Control: tags -1 wontfix Dear Christoph, On 05/24/2018 09:43 AM, Christoph Biedl wrote: > This affects your package fgrun since the list address > pkg-fgfs-c...@lists.alioth.debian.org used in the Maintainer: field was > not transferred to the alioth-lists service that provides a > continuation for the lists in the @lists.alioth.debian.org domain. thank you for this bug report. However, this package is not maintained any longer and we've already filed a request for removal from Debian (#898062). The stable package remains. But I don't think an upload is justified to fix the maintainer email there. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#899074: FTBFS: test #4: Couldn't resolve host name; missing B-Dep on netbase
Adam, On 05/18/2018 10:47 PM, Adam Borowski wrote: > The reason is that your package requires a configured resolver setup -- at > least enough to have "localhost" in /etc/hosts. thank you for your bug report. The proposal to add netbase to B-Depends sounds reasonable to me. I'll make sure this comes along with my next upload. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#898062: RM: fgrun -- RoM; unmaintained and obsolete
Package: ftp.debian.org X-Debbugs-Cc: team+flightg...@tracker.debian.org, to...@debian.org Dear FTP Masters, fgrun is another separate launcher application for flightgear, which does not seem to be maintained any more. I'm therefore requesting the removal from unstable on behalf of the Flightgear Crew. The last upstream release dates back to Sep 2016 [0]. As FlightGear itself started to offer a similar integrated functionality, I think most users already switched from fgrun, already. Kind Regards Markus Wanner [0]: Youngest release tag: https://sourceforge.net/p/flightgear/fgrun/ci/3fb3be193518d22790333967cdadb6f89dbdf282/log/ signature.asc Description: OpenPGP digital signature
Bug#898043: RM: fgo -- RoM; unmaintained and obsolete
On 05/06/2018 04:03 PM, Adam D. Barratt wrote: > From https://wiki.debian.org/ftpmaster_Removals#Removals_from_testing.2 > C_stable_and_oldstable : Thank you. I'll follow that procedure for fgrun. > I'm assuming that there's no desperate need for the testing removal to > be expedited, so starting with unstable and letting things take their > natural course is the correct approach; re-reassigning. Correct, thanks. Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#898043: RM: fgo -- RoM; unmaintained and obsolete
Control: user -1 release.debian@packages.debian.org On 05/06/2018 01:51 PM, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Sun, 2018-05-06 at 13:34 +0200, Markus Wanner wrote: >> Control: reassign -1 release.debian.org >> Control: user -1 user release.debian@packages.debian.org >> Control: usertags -1 rm >> thanks >> >> I figured I should have asked for a removal from testing, targeting >> the >> Release Managers. >> > > If it is indeed unmaintained and obsolete, why shouldn't it be removed > from unstable? Sorry for the confusion. I'd appreciate the package to disappear from testing and unstable. It shall not be part of buster. I was trying to follow instructions here, and considered only unstable, first: https://wiki.debian.org/ftpmaster_Removals I'm still not quite clear what the best approach is for requesting a removal from testing and unstable (which I'll have to repeat for fgrun). Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#898043: RM: fgo -- RoM; unmaintained and obsolete
Control: reassign -1 release.debian.org Control: user -1 user release.debian@packages.debian.org Control: usertags -1 rm thanks I figured I should have asked for a removal from testing, targeting the Release Managers. Regards Markus signature.asc Description: OpenPGP digital signature
Bug#898043: RM: fgo -- RoM; unmaintained and obsolete
Package: ftp.debian.org X-Debbugs-Cc: team+flightg...@tracker.debian.org X-Debbugs-Cc: pkg-fgfs-c...@lists.alioth.debian.org Dear FTP Masters, fgo is a separate launcher application for flightgear, which does not seem maintained any longer. I'm therefore requesting the removal from unstable on behalf of the Flightgear packaging team. The last upstream release dates back to Nov 2014 [0]. Florent Rougon started a fork called ffgo, IIRC because the original author of fgo was not responsive. However, we decided not to package ffgo for Debian, either [1]. Both became somewhat obsolete since FlightGear itself started to offer a similar integrated functionality. Therefore I think most users switched await from fgo or ffgo, already. Kind Regards Markus Wanner [0]: List of releases of fgo: https://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo/download [1]: Cancelled ITP for ffgo: https://bugs.debian.org/871043 signature.asc Description: OpenPGP digital signature
Bug#895332: marked as done (flightgear: no flightgear package present in Buster repo)
Control: reopen -1 Control: retitle -1 flightgear: FTBFS on armel and armhf Hello Tobias, On 04/10/2018 02:21 PM, Debian Bug Tracking System wrote: > This means that you claim that the problem has been dealt with. I don't quite think that's an appropriate response. The issue clearly hasn't been resolved, yet. Given there's not FTBFS for the build failure on arm, I suggest we relabel this one. Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#863723: dput-ng: skip `please login: To accept ssh-rsa hostkey [...]`
Hello Nico,
I recently run into the same issue. Until I figured dput-ng uses
paramiko underneath, which in turn reads the usual
/etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files.
Once you add the host key to the list of known hosts, either system wide
or for the user trying to connect, dput-ng can well upload without the
quoted message.
To retrieve the ssh key use:
ssh-keyscan -t rsa -H ${HOST}
Hope this helps.
Kind Regards
Markus Wanner
signature.asc
Description: OpenPGP digital signature
Bug#889556: monotone: (Build-)Depends on obsolete libbotan1.10-dev
On 03/09/2018 10:32 AM, Jack Lloyd wrote: > 2.4.0 was just (in last week or so) packaged for buster - > https://packages.debian.org/buster/libbotan-2-4 oh, very nice. Looks like I searched only "stable". Thank you for the hint. Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#889556: monotone: (Build-)Depends on obsolete libbotan1.10-dev
Hello Ondřej, On 02/04/2018 03:14 PM, Christian Hofstaedtler wrote: > your package monotone (build-)depends on botan1.10, which itself is > obsolete. Upstream will end security support at the end of 2018, so it > must not be part of buster. any plans on packaging Botan 2 for Debian? Otherwise I might start packaging it, as we'll need it for monotone. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#818377: improve courier-maildrop compatibility
On 01/02/2018 01:15 AM, Josip Rodin wrote: > All of those changes related to HAVE_COURIER sound like something that > should be possible to figure out on runtime. That's exactly what I thought as well and proposed, but upstream rejected as an additional security risk. > I still don't see a rationale for that. The existence of those measly few > lines about the HAVE_COURIER define, that we then have to interpret and > reverse-engineer and whatnot - simply don't constitute a valid rationale > for adding back a binary with suid root by default. Exactly my line of thought as well. > I think we need to ask Sam to document this properly, and only then proceed > with any further considerations. That's fine with me. Kind Regards Markus Wanner
Bug#818377: improve courier-maildrop compatibility
On 12/29/2017 09:17 PM, Josip Rodin wrote: > On Sun, Dec 24, 2017 at 09:17:28AM +0900, Osamu Aoki wrote: >> Another option is create another wrapper code such as maildrop-suid-root >> which is a SUID on root program and let it calls maildrop in upstream. >> And make courier call this new code. This needs upstream cooperation. I brought up the issue on their mailing list, but upstream wasn't exactly cooperative. They think of maildrop being available in two different flavours: standalone and courier-mta bundle. >> I don't want to maintain any SUID root program. Too much >> responsibility. If you are willing to take over this package >> maintenance, I can help 2 binary package script. > > It doesn't make sense to add a new setuid root binary in the maildrop > package. Whatever problem there is to solve, more setuid root by default > is simply not a legitimate solution without a big fat obvious rationale > about how it's unavoidable. Let's not jump to any such conclusions > beforehand. I wonder if SUID is related at all. In my own setup, while using virtual domains in combination with maildrop, it wouldn't even need SGID, I think. But I'd have to check why it was SUID to begin with. Or if it is in the variant upstream installs. Kind Regards Markus Wanner
Bug#873877: jessie-pu: package flightgear/3.0.0-5+deb8u3
On 11/19/2017 11:47 PM, Adam D. Barratt wrote: > Technically it had only been accepted into oldstable-new. I've just > flagged it for acceptance into opu. Ah, I didn't fully parse the subject, and the body of the "...change ACCEPTED into" only said: > Mapping jessie to oldstable. > Mapping oldstable to oldstable-proposed-updates. Thank you for clarification and for taking care. Kind Regards Markus Wanner
Bug#873877: jessie-pu: package flightgear/3.0.0-5+deb8u3
On 11/18/2017 07:53 PM, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2017-08-31 at 21:55 +0200, Markus Wanner wrote: >> here's an update for jessie, fixing #873439 (CVE-2017-13709). It's >> based on a patch and debdiff by Florent Rougon. The corresponding >> stretch-pu request is #873754. >> > > Please go ahead; sorry for not getting back to you sooner. No problem. I updated the timestamp and also added a "Closes: #873439" to the changelog. I hope that change is still acceptable. The upload has been accepted into oldstable-proposed-updates. Kind Regards Markus Wanner
Bug#875954: courier-mta: /usr/sbin/sendmail has wrong permissions
Control: tags -1 moreinfo Hello Bernard, thanks for taking time to file a bug report. On 09/16/2017 03:47 PM, Bernard wrote: > sendmail gets installed with setgid but has to be installed with setuid. Could you please elaborate on why setgid is not enough (with the group set to courier)? The change would grant extra permissions to sendmail, which I'm hesitant to implement. Especially as I can successfully send emails from normal user accounts using sendmail with setgid. On 09/16/2017 07:23 PM, Willi Mann wrote: > according to the previous maintainer, this bug was fixed in version > 0.75.0-15. However, I never verified that (I reported the bug back > then) Thanks for this link. Interestingly, that very issue asked for the exact opposite: changing from setuid to setgid. Willi Mann wrote this: > Changing the permission from 4755 to 2755 (setgid instead of setuid bit) > solves > the issue. Given the OP reports that sendmail currently has setgit set and that's the case on my box as well, I conclude that Ondřej has properly applied the patch asked for in #812235. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#875659: courier: FTBFS due to openssl vs gnutls confusion
Source: courier Version: 0.78.0-1 Severity: serious Tags: confirmed pending Just a tracker issue for myself: Looks like libs/tcpd/tlspasswordcache.c of 0.78.0 tries to use some OpenSSL code, while we want it to link against GnuTLS. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#875276: [patch] update symbols file for -O3 builds
Control: tags -1 +pending On 09/10/2017 10:22 AM, Matthias Klose wrote: > update symbols file for -O3 builds. some templates are inlined with -O3, and > aren't part of the ABI in any case. Thank you for your patch. I applied it to the repo on alioth and it should be part of the next upload (0.68.0-4 or higher). Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#873439: [pkg-fgfs-crew] Bug#873439: flightgear: CVE-2017-13709: Incorrect access control
Hi, while this has been fixed in unstable, I have also requested to upload to stable and unstable. Here are the issues and versions for reference: stable:#873754 1:2016.4.4+dfsg-3+deb9u1 oldstable: #873877 3.0.0-5+deb8u3 Assuming the release team approves the uploads, the fix should enter Debian stable and oldstable with the next point release. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#873754: stretch-pu: package flightgear/1:2016.4.4+dfsg-3+deb9u1
Hi, sorry for initially messing up the release names. This issue and the attached debdiff should target stretch alias stable. I just filed another similar issue for jessie: #873877. Unstable already got the security fix with 1:2017.2.1+dfsg-4. The original security issue reported by Florent is #873439 (CVE-2017-13709 [0]). Kind Regards Markus Wanner [0]: https://security-tracker.debian.org/tracker/CVE-2017-13709 signature.asc Description: OpenPGP digital signature
Bug#873877: jessie-pu: package flightgear/3.0.0-5+deb8u3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
Dear Release Team,
here's an update for jessie, fixing #873439 (CVE-2017-13709). It's based
on a patch and debdiff by Florent Rougon. The corresponding stretch-pu
request is #873754.
A bit about the security issue: Malicious add-ons could write arbitrary
user's files, possibly even executable ones. The fix is in two parts,
back-ported to older releases by Florent Rougon.
Please verify the attached debdiff for fixing the issue in jessie with
the next point release.
Kind Regards
Markus Wanner
diff -Nru flightgear-3.0.0/debian/changelog flightgear-3.0.0/debian/changelog
--- flightgear-3.0.0/debian/changelog 2017-07-02 14:39:08.0 +0200
+++ flightgear-3.0.0/debian/changelog 2017-08-31 09:09:03.0 +0200
@@ -1,3 +1,16 @@
+flightgear (3.0.0-5+deb8u3) jessie; urgency=high
+
+ [ Florent Rougon ]
+ * Add two patches for CVE-2017-13709:
+ - call-fgInitAllowedPaths-earlier-c7a2ae.patch (required by the next
+patch)
+ - CVE-2017-13709-FGLogger-2a5e3d.patch
+
+ [ Markus Wanner ]
+ * Massage patch meta information to fit DEP-3.
+
+ -- Markus Wanner <mar...@bluegap.ch> Thu, 31 Aug 2017 21:44:41 +0200
+
flightgear (3.0.0-5+deb8u2) jessie; urgency=high
* Add patch restrict-save-flightplan-secu-fix-faf872.patch: prevent
diff -Nru
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
---
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
1970-01-01 01:00:00.0 +0100
+++
flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
2017-08-31 08:56:58.0 +0200
@@ -0,0 +1,54 @@
+Description: Call fgInitAllowedPaths earlier: after Options::processOptions
+ Call fgInitAllowedPaths() right after Options::processOptions() (which,
+ among other things, determines $FG_ROOT and processes
+ --allow-nasal-read). This way, fgInitAllowedPaths() can be used in much
+ more code, such as when initializing subsystems.
+ .
+ (cherry picked from commit c7a2aef59979af3e9ff22daabb37bdaadb91cd75)
+Forwarded: not-needed
+Author: Florent Rougon <f.rou...@free.fr>
+
+--- a/src/Main/fg_init.cxx
b/src/Main/fg_init.cxx
+@@ -1023,7 +1023,12 @@
+ fgGetNode("/sim")->removeChild("aircraft-dir");
+ fgInitAircraft(true);
+ flightgear::Options::sharedInstance()->processOptions();
+-
++
++// Rebuild the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ render = new FGRenderer;
+ render->setEventHandler(eventHandler);
+ globals->set_renderer(render);
+--- a/src/Main/main.cxx
b/src/Main/main.cxx
+@@ -461,7 +461,12 @@
+ } else if (configResult == flightgear::FG_OPTIONS_EXIT) {
+ return EXIT_SUCCESS;
+ }
+-
++
++// Set the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ // Initialize the Window/Graphics environment.
+ fgOSInit(, argv);
+ _bootstrap_OSInit++;
+--- a/src/Scripting/NasalSys.cxx
b/src/Scripting/NasalSys.cxx
+@@ -800,9 +800,6 @@
+ .member("singleShot", ::isSingleShot, ::setSingleShot)
+ .member("isRunning", ::isRunning);
+
+-// Set allowed paths for Nasal I/O
+-fgInitAllowedPaths();
+-
+ // Now load the various source files in the Nasal directory
+ simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal"));
+ loadScriptDirectory(nasalDir);
diff -Nru flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
--- flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
1970-01-01 01:00:00.0 +0100
+++ flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
2017-08-31 08:57:36.0 +0200
@@ -0,0 +1,68 @@
+Description: Security: don't allow FGLogger to overwrite arbitrary files
+ Since the paths of files written by FGLogger come from the property
+ tree[1], they must be validated before we decide to write to these
+ files.
+ .
+ [1] Except for the "empty" case, which uses the default name
+ 'fg_log.csv'.
+ .
+ This fixes CVE-2017-13709.
+ .
+ (cherry picked from commit 2a5e3d06b2c0d9f831063afe7e7260bca456d679)
+Forwarded: not-needed
+Author: Florent Rougon <f.rou...@free.fr>
+
+--- a/src/Main/logger.cxx
b/src/Main/logger.cxx
+@@ -11,10 +11,14 @@
+
+ #include
+ #include
++#include
+
+ #include
++#includ
Bug#873754: jessie-pu: package flightgear/1:2016.4.4+dfsg-3+deb9u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
Dear Release Team,
yet another security fix for flightgear, that's not worth a DSA
according to Salvatore Bonaccorso.
A bit about the security issue: Malicious add-ons could write arbitrary
user's files, possibly even executable ones. The fix is in two parts,
back-ported to older releases by Florent Rougon.
Please verify the attached debdiff for fixing the issue in stretch with
the next point release.
Kind Regards
Markus Wanner
diff -Nru flightgear-2016.4.4+dfsg/debian/changelog
flightgear-2016.4.4+dfsg/debian/changelog
--- flightgear-2016.4.4+dfsg/debian/changelog 2017-05-19 19:10:15.0
+
+++ flightgear-2016.4.4+dfsg/debian/changelog 2017-08-30 16:06:14.0
+
@@ -1,3 +1,12 @@
+flightgear (1:2016.4.4+dfsg-3+deb9u1) stable; urgency=medium
+
+ * Add patches init-allowed-paths-earlier-secu-fix-f372d7.patch and
+prevent-arbitrary-file-writes-secu-fix-58d8e1.patch: prevent
+malicious add-ons from overriding arbitrary files.
+Closes: #873439 (CVE-2017-13709)
+
+ -- Markus Wanner <mar...@bluegap.ch> Wed, 30 Aug 2017 18:06:14 +0200
+
flightgear (1:2016.4.4+dfsg-3) unstable; urgency=medium
* Team upload.
diff -Nru
flightgear-2016.4.4+dfsg/debian/patches/init-allowed-paths-earlier-secu-fix-f372d7.patch
flightgear-2016.4.4+dfsg/debian/patches/init-allowed-paths-earlier-secu-fix-f372d7.patch
---
flightgear-2016.4.4+dfsg/debian/patches/init-allowed-paths-earlier-secu-fix-f372d7.patch
1970-01-01 00:00:00.0 +
+++
flightgear-2016.4.4+dfsg/debian/patches/init-allowed-paths-earlier-secu-fix-f372d7.patch
2017-08-30 07:03:19.0 +
@@ -0,0 +1,62 @@
+Description: Call fgInitAllowedPaths earlier: after Options::processOptions
+ Call fgInitAllowedPaths() right after Options::processOptions() (which,
+ among other things, determines $FG_ROOT and processes
+ --allow-nasal-read). This way, fgInitAllowedPaths() can be used in much
+ more code, such as when initializing subsystems.
+ .
+ (cherry picked from commit c7a2aef59979af3e9ff22daabb37bdaadb91cd75)
+ .
+ In preparation for the real security fix following this commit.
+Origin: upstream,
https://sourceforge.net/p/flightgear/flightgear/ci/f372d7548ad7114aed14135dcc566ea326c24beb/
+Author: Florent Rougon
+
+diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx
+index ea9d9b5ef..47987a363 100644
+--- a/src/Main/fg_init.cxx
b/src/Main/fg_init.cxx
+@@ -1070,7 +1070,12 @@ void fgStartNewReset()
+ fgInitGeneral(); // all of this?
+
+ flightgear::Options::sharedInstance()->processOptions();
+-
++
++// Rebuild the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ // PRESERVED properties over-write state from options, intentionally
+ if ( copyProperties(preserved, globals->get_props()) ) {
+ SG_LOG( SG_GENERAL, SG_INFO, "Preserved state restored successfully"
);
+diff --git a/src/Main/main.cxx b/src/Main/main.cxx
+index bed7e2954..fd2fb575c 100644
+--- a/src/Main/main.cxx
b/src/Main/main.cxx
+@@ -515,7 +515,12 @@ int fgMainInit( int argc, char **argv )
+ } else if (configResult == flightgear::FG_OPTIONS_EXIT) {
+ return EXIT_SUCCESS;
+ }
+-
++
++// Set the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ // Initialize the Window/Graphics environment.
+ fgOSInit(, argv);
+ _bootstrap_OSInit++;
+diff --git a/src/Scripting/NasalSys.cxx b/src/Scripting/NasalSys.cxx
+index 1002b08dc..6c6fa1b48 100644
+--- a/src/Scripting/NasalSys.cxx
b/src/Scripting/NasalSys.cxx
+@@ -886,9 +886,6 @@ void FGNasalSys::init()
+ .member("singleShot", ::isSingleShot, ::setSingleShot)
+ .member("isRunning", ::isRunning);
+
+-// Set allowed paths for Nasal I/O
+-fgInitAllowedPaths();
+-
+ // Now load the various source files in the Nasal directory
+ simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal"));
+ loadScriptDirectory(nasalDir);
diff -Nru
flightgear-2016.4.4+dfsg/debian/patches/prevent-arbitrary-file-writes-secu-fix-58d8e1.patch
flightgear-2016.4.4+dfsg/debian/patches/prevent-arbitrary-file-writes-secu-fix-58d8e1.patch
---
flightgear-2016.4.4+dfsg/debian/patches/prevent-arbitrary-file-writes-secu-fix-58d8e1.patch
1970-01-01 00:00:00.0 +
+++
flightgear-2016.4.4+dfsg/debian/patches/prevent-arbitrary-file-writes-secu-fix-58d8e1.patch
2017-08-30 07:04:40.0 +
@@ -0,0 +1,96 @@
+Description: Security: don't allow FGLogger to overw
Bug#871638: [Pkg-rust-maintainers] Bug#871638: rustc panics when trying to list the target cpus if the current directory does not exist anymore
Control: tags -1 +confirmed Control: found -1 1.18.0+dfsg1 Hello Alex, On 08/10/2017 10:32 AM, Alex Riesen wrote: > just trying to run the commands below (with or without RUST_BACKTRACE) causes > rustc to panic. The removal of the directory was originally not intentional, > so a crash for such harmless command was a bit of surprise. thanks for your bug report, I can confirm this issue even with the current version of rustc (in sid). Note that with a current nightly (rustc 1.21.0-nightly (cbbe17aa7 2017-08-07)) obtained via rustup, I instead get the following error: error: couldn't find value of CARGO_HOME info: caused by: No such file or directory (os error 2) Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#871586: courier FTBFS with libcourier-unicode-dev 2.0-1
Control: tags -1 +confirmed +pending Hi, thanks for filing this issue. Looks like courier 0.77.0 is required together with the newer libcourier-unicode version. An upload of the former should be ready soon-ish. Kind Regards Markus Wanner
Bug#841301: ITP: libwlc -- wlc a compositor library for Wayland
Hello Stefanos, I'm interested in libwlc as well and wonder what the status of your packaging efforts is. On Wed, 28 Dec 2016 15:05:20 +0200 Stefanos Boglou wrote: > I have made a few prototype packages and seems to be not that difficult. Good to read. > There are a few issues however: > 1) in the latest released version it does not seem to detect the installed > wayland-protocols package and instead uses the one bundled with it but it > is fixed in master Seems fixed in 0.0.10. > 2) libchck is not packaged for debian thus it must be included in the > source package Yeah, I don't think it warrants its own package just yet. > 3) I have not taken the time to make shlib definitions yet Sure, usually one of the later things. > 4) While the whole libwlc/sway seems to mostly work it has a few show > stopping bugs that propably should be addressed first before even thinking > about I'm currently interested in way-cooler as well (not in any way stating I'm going to package that one, though). Are you aware of any specific libwlc bugs? I'm a DD and could help you package the library and/or act as a sponsor, if you wish. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#871043: ITP: ffgo -- a launcher for flightgear
Subject: ITP: ffgo -- a launcher for flightgear Package: wnpp Severity: wishlist Owner: Markus Wanner <mar...@bluegap.ch> * Package name: ffgo Version: 1.12.5 Upstream Author: Florent Rougon * URL: http://frougon.net/projects/FFGo/ * License: GPL 3+ with OpenSSL exception Programming Lang: Python (3) Description: powerful graphical launcher for FlightGear FFGo is a fast and simple way to start a FlightGear session. Like other such applications (e.g., FGRun, FGo!, FGx), FFGo allows one to easily select the aircraft, airport, scenario, etc. One thing that distinguishes it from other such applications is the text window allowing one to write any other, more advanced command line options that will be passed to FlightGear. This is similar, but much more convenient and powerful, to editing the .fgfsrc configuration file. The main difference in power compared to editing .fgfsrc or using FGo! comes from FFGo's use of CondConfigParser to process the user's configuration. In addition to this, FFGo offers: * an easy setup (Preferences dialog); * convenient selection of aircraft and startup airport or carrier; * possibility to choose between identically-named aircrafts based on which directory they are stored in (using tooltips in the aircraft list); * easy selection of startup runway or parking position, offering startup locations from apt.dat if there is no groundnet-defined parking position for the selected airport; * detailed airport, runway, helipad and parking tooltips. Airport tooltips show things such as airport type (land airport, seaplane base or heliport), latitude, longitude, elevation, number of land runways, water runways, helipads, magnetic variation... Runway/helipad tooltips show runway type, length and width, surface type, magnetic as well as true heading, etc. Parking tooltips show similar information as runway tooltips, plus maximum aircraft radius, reserved airline codes... Note: MagneticField from the geographiclib-tools package is needed for magnetic data. * easy consulting of METAR data for the nearest station relatively to the selected airport (if any); * a powerful Airport Finder dialog allowing one to easily find airports using various criteria: distance to a chosen, “reference airport”; number of land runways, water runways, or helipads; length of the longest or shortest runway in the airport, etc. The table of results displays, among others, the distance and bearings between the reference airport and each “result airport”. It can be sorted according to any column with a simple click on the column header. * a GPS Tool dialog allowing one to find the distance, initial and final bearings for the shortest path between two given airports. The dialog also computes the flight duration for a given ground speed, and vice versa. * easy selection of one or more scenarios, allowing one to browse the description of each available scenario; * realtime preview of the arguments that will be passed to fgfs (FlightGear) if the “Run FG” button is pressed; * the possibility to copy to the clipboard a shell command that is equivalent to what FFGo will do if the “Run FG” button is pressed; * the option to translate fgfs' --parkpos option into the corresponding combination of --lat, --lon and --heading options. This is useful when the --parkpos option is broken in FlightGear; * easy viewing and saving of FlightGear output (log); * automatic FFGo + FlightGear log saving and rotating. * ability to read and merge an arbitrary number of in-scenery-paths, uncompressed or gzip-compressed apt.dat files (compliant with a feature introduced in FlightGear 2016.4.0). Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#869935: flightgear: FTBFS due to unit tests
Source: flightgear Version: 1:2017.2.1+dfsg-1 Severity: serious Tags: confirmed pending https://buildd.debian.org/status/package.php?p=flightgear=sid The following tests FAILED: 1 - test_navs (Failed) 2 - test_flightplan (Failed) 4 - autosaveMigration (Failed) Looks like this is caused by running the tests in parallel. I'm working on a fix. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#866975: courier-authlib FTBFS on 32bit: missing symbols
Control: tags -1 +confirmed Hi Adrian, thanks for the bug report, I'll correct the symbols for 32bit systems. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#862891: jessie-pu: package flightgear/3.0.0-5+deb8u2
Hi Cyril, On 07/02/2017 11:14 PM, Cyril Brulebois wrote: > Markus Wanner <mar...@bluegap.ch> (2017-07-02): >> On 28.06.2017 00:43, Cyril Brulebois wrote: >>> I don't see 3.0.0-5+deb8u1 anywhere? >>> >>> flightgear | 3.0.0-5 | oldstable | source >>> flightgear | 3.0.0-5 | oldstable-kfreebsd | source >>> flightgear | 1:2016.4.4+dfsg-3 | stable | source >>> flightgear | 1:2016.4.4+dfsg-3 | testing| source >>> flightgear | 1:2016.4.4+dfsg-3 | unstable | source >>> flightgear | 1:2016.4.4+dfsg-3 | unstable-debug | source >>> >>> What's up with the security upload? sorry, I misunderstood this as you asking for an upload of deb8u2. >>> (Also, you should be targetting “jessie” directly instead of “stable”.) (Just out of curiosity: is there a difference between uploading to "jessie" versus (now) "oldstable"?) > When a pu request is marked with +moreinfo, you're supposed to be giving > feedback. Uploads should only happen after you're given a green light > (through a +confirmed). Okay, I'm sorry I didn't follow the procedures properly. >> I just uploaded 3.0.0-5+deb8u2 for "jessie", as you asked for. >> Including a very minor modification of the patch for it to compile, >> again, as discussed with upstream. > > I did request the target change, but not really the upload; I still > don't get why your changelog has a 3.0.0-5+deb8u1 entry which doesn't > seem to have made it to the archive. I see 3.0.0-5+deb8u1 in oldstable: https://tracker.debian.org/pkg/flightgear https://packages.debian.org/source/oldstable/flightgear Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#862891: jessie-pu: package flightgear/3.0.0-5+deb8u2
Hello Cyril, On 28.06.2017 00:43, Cyril Brulebois wrote: > I don't see 3.0.0-5+deb8u1 anywhere? > > flightgear | 3.0.0-5 | oldstable | source > flightgear | 3.0.0-5 | oldstable-kfreebsd | source > flightgear | 1:2016.4.4+dfsg-3 | stable | source > flightgear | 1:2016.4.4+dfsg-3 | testing| source > flightgear | 1:2016.4.4+dfsg-3 | unstable | source > flightgear | 1:2016.4.4+dfsg-3 | unstable-debug | source > > What's up with the security upload? > > (Also, you should be targetting “jessie” directly instead of “stable”.) I'm sorry. After a build failure with the proposed patch and another loop with upstream, this slipped from my todo list. Thank you for the reminder. I just uploaded 3.0.0-5+deb8u2 for "jessie", as you asked for. Including a very minor modification of the patch for it to compile, again, as discussed with upstream. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#866221: postgresql-9.4-postgis-2.1 uninstallable under Stretch
Hello Élie, On 06/28/2017 03:28 PM, Élie Bouttier wrote: > I upgraded from Jessie with postgresql-9.4 to Stretch which brings > postgresql-9.6. > The postgresql-9.4 package from Jessie is still installable under Stretch in > order to run the pg_upgradecluster utility. > However, my cluster is half-broken, the postgresql-9.4-postgis-2.1 having > been uninstalled (and postgresql-9.6-postgis-2.3 installed). that's what the pgapt [0] repository is for. Please try installing postgresql-9.4-postgis-2.1 (for stretch) from there. > I suppose the postgresql-9.4-postgis-2.1 package should be installable under > Stretch (like postgresql-9.4) to allow an cluster update. No, postgresql-9.4-postgis-2.1 from jessie is expected to be compiled and work for jessie, not stretch. The problem basically is that Debian only ever supports a single Postgres (major) version, where as you need to have multiple installed in parallel for upgrades (with reasonably short downtimes). Please let us know if pgapt is a feasible solution for you and whether or not the upgrade worked with the postgis package from there. Kind Regards Markus Wanner [0]: PgApt https://wiki.postgresql.org/wiki/Apt signature.asc Description: OpenPGP digital signature
Bug#862891: jessie-pu: package flightgear/3.0.0-5+deb8u2
Control: -1 tags -moreinfo Hi, Tobias uploaded flightgear-1:2016.4.4+dfsg-3 last Friday (thanks, Tobias), including the security fix. It already migrated to testing as well a couple hours ago. Please proceed with this jessie-pu bug. Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#862891: jessie-pu: package flightgear/3.0.0-5+deb8u2
Adam, thank you for your feedback. On 05/18/2017 03:07 PM, Adam D. Barratt wrote: > So far as I can tell, having looked at the BTS and Security Tracker, and > the description of the CVE, this issue also affects the flightgear > package in unstable and is not yet fixed there. That's correct, yes. > Assuming that's correct, > please ensure that unstable is fixed first and then come back to us; if > it's not correct, please get the metadata fixed. I focused on stable, first, thinking of it as a security issue. The fix for unstable is somewhat different, but also being prepared. I'll report back when it's fixed, there. > Indeed, because the main archive rejected the upload before it made it > as far as the p-u-new queue. I don't remember why and it was > suffficiently long ago that the data files are no longer publicly > available in order to check. I think that was the PGP key deprecation issue on my side. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#862891: jessie-pu: package flightgear/3.0.0-5+deb8u2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
Dear Release Team,
as per Salvatore Bonaccorso, the current security fix for flightgear
doesn't warrant a DSA on its own (see below). Is it okay to upload to
'stable'?
A debdiff against the current version in stable-sec (3.0.0-5+deb8u1) is
attached. Please note that stable itself is still at 3.0.0-5 and doesn't
offer the first (and related) security fix.
Kind Regards
Markus Wanner
On 05/17/2017 08:57 AM, Salvatore Bonaccorso wrote:
> Hi,
>
> On Wed, May 17, 2017 at 08:49:19AM +0200, Moritz Muehlenhoff wrote:
>> On Wed, May 17, 2017 at 07:20:15AM +0200, Salvatore Bonaccorso wrote:
>>> Hi Markus,
>>>
>>> On Fri, May 12, 2017 at 07:57:23PM +0200, Markus Wanner wrote:
>>>> Florent,
>>>>
>>>> On 05/12/2017 07:33 PM, Florent Rougon wrote:
>>>>> We'd like to draw your attention on the following fix for FlightGear:
>>>>
>>>> thanks for your heads-up, I'll take care of preparing an upload for the
>>>> affected Debian packages.
>>>
>>> Thanks. Filled as well #862689 in the BTS in meanwhile.
>>>
>>> For stable: We think this does need a DSA on its own, can you schedule
>> ^ not
>>
>> :-)
>
> Autsch, yes of course ... sorry for confusion caused (hope this still
> was clear from context :)).
>
> Regards,
> Salvatore
diff -Nru flightgear-3.0.0/debian/changelog flightgear-3.0.0/debian/changelog
--- flightgear-3.0.0/debian/changelog 2016-12-14 09:43:00.0 +
+++ flightgear-3.0.0/debian/changelog 2017-05-17 10:46:18.0 +
@@ -1,3 +1,11 @@
+flightgear (3.0.0-5+deb8u2) stable; urgency=high
+
+ * Add patch restrict-save-flightplan-secu-fix-faf872.patch: prevent
+overriding arbitrary files from the "save-flightplan" FGCommand.
+Closes: #862689 (CVE-2017-8921).
+
+ -- Markus Wanner <mar...@bluegap.ch> Tue, 16 May 2017 21:37:27 +0200
+
flightgear (3.0.0-5+deb8u1) jessie-security; urgency=high
* Add patch route-manager-secu-fix-280cd5.patch (security fix preventing
diff -Nru
flightgear-3.0.0/debian/patches/restrict-save-flightplan-secu-fix-faf872.patch
flightgear-3.0.0/debian/patches/restrict-save-flightplan-secu-fix-faf872.patch
---
flightgear-3.0.0/debian/patches/restrict-save-flightplan-secu-fix-faf872.patch
1970-01-01 00:00:00.0 +
+++
flightgear-3.0.0/debian/patches/restrict-save-flightplan-secu-fix-faf872.patch
2017-05-17 09:16:50.0 +
@@ -0,0 +1,36 @@
+Description: Security fix: don't allow overwriting arbitrary files
+ the previous fix 280cd523 missed commandSaveFlightPlan
+ .
+ backported from faf872e7, fixes CVE-2017-8921.
+Author: Rebecca N. Palmer <rebecca_pal...@zoho.com>
+ Florent Rougon <f.rou...@free.fr>
+Origin: upstream,
https://sourceforge.net/p/flightgear/flightgear/ci/c8250b10bb9a116889f831d2299678b0ef70fec2/
+
+--- a/src/Autopilot/route_mgr.cxx
b/src/Autopilot/route_mgr.cxx
+@@ -75,7 +75,24 @@
+ {
+ FGRouteMgr* self = (FGRouteMgr*) globals->get_subsystem("route-manager");
+ SGPath path(arg->getStringValue("path"));
+- return self->saveRoute(path);
++ const std::string authorizedPath = fgValidatePath(path.realpath(),
++true /* write */);
++
++ if (!authorizedPath.empty()) {
++return self->saveRoute(SGPath(authorizedPath));
++ } else {
++const SGPath proposedPath = SGPath(globals->get_fg_home()) / "Export";
++std::string msg =
++ "The route manager was asked to write the flightplan to '" +
++ path.str() + "', but this path is not authorized for writing. " +
++ "Please choose another location, for instance in the $FG_HOME/Export "
++ "folder (" + proposedPath.str() + ").";
++
++SG_LOG(SG_AUTOPILOT, SG_ALERT, msg);
++modalMessageBox("FlightGear", "Unable to write to the specified file",
++msg);
++return false;
++ }
+ }
+
+ static bool commandActivateFlightPlan(const SGPropertyNode* arg)
diff -Nru flightgear-3.0.0/debian/patches/series
flightgear-3.0.0/debian/patches/series
--- flightgear-3.0.0/debian/patches/series 2016-12-14 09:13:44.0
+
+++ flightgear-3.0.0/debian/patches/series 2017-05-16 20:18:39.0
+
@@ -5,3 +5,4 @@
6a30e7.patch
route-manager-secu-fix-280cd5.patch
fix-missing-lX11-in-link-commands.patch
+restrict-save-flightplan-secu-fix-faf872.patch
signature.asc
Description: OpenPGP digital signature
Bug#861442: unblock: (pre-approval) courier/0.76.3-5
Control: tags -1 -moreinfo On 05/07/2017 10:42 PM, Niels Thykier wrote: > Ack, please go ahead and remove the moreinfo tag once the upload has > been processed and built on all relevant release architectures. Uploaded and built on all release arches (and most non-release ones as well). Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#436266: courier-imap: Do not purge messsages from trash by default
Control: tags -1 +upstream Hi, reading through this bug, I can understand the motivation of the OP to to not delete messages from the trash by default. It's a conservative default. However, to me, the main reason speaking against changing the default is that such a change would increase the deviation of the Debian provided package from upstream. And they might have their good reasons to choose such a default. I'm therefore going to discuss this with upstream. Olaf van der Spek <o...@xwis.net> wrote: > I'm now running with "IMAP_EMPTYTRASH=" but now all mails from my trash > folder are deleted. > Could this be another bug? That clearly sounds like a bug to me. I'll check this and report back. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#860835: flightgear: New upstream release
Control: tags -1 +confirmed Hi, > Latest upstream is FlightGear 2017.1.3. > It would be great if Debian packages were updated. thanks for filing this issue. I'm currently focusing on the stretch release and plan to update the Flightgear packages only after that release (or at least after I'm done with my tasks for that). Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#861442: unblock: (pre-approval) courier/0.76.3-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, only after the freeze, I realized that courier-mta is unmaintained and got orphaned a couple moons ago. As I still use and like that MTA, but it broke after an upgrade to stretch, I opted to adopt courier and continue maintenance (#823807). I realize it's pretty late in the process, but I'd appreciate keeping courier in stretch. In any case, I plan to continue maintaining the package for later releases. I tried to keep the changes minimal, but mainly focused on getting things to work. Quite a few changes for different important issues accumulated. Note that I already have this version of courier in use on stretch (it actually processed this very email). Please indicate if any of the parts are not appropriate to be fixed for stretch. I'm happy to prepare a corrected candidate. However, if too many bugs remain unfixed, I'd rather vote for a removal from stretch, than shipping something that breaks after an upgrade. I commented the portions of the diff in the attached debdiff, in relation to the changelog item added (patch can still apply the diff). To simplify discussion via email, here's a copy of the proposed changes: item 1: Fix Debian patch 0012-Define-and-use-PEMFILE-in-mkesmtpdcert.patch: do not invoke 'install -b' twice from mkesmtpdcert, eliminating unnecessary backup files not cleaned up by purge. Closes: #847348. item 2: Add patch 0026-Fix-TLS-verification-for-CNAMEs.patch: correct TLS verification when DNS answers with CNAMEs. Closes: #860762. item 3: Systemd service files: Correct delimiter of dependencies. Closes: #860765. (comma replaced by space) item 4: Fix init scripts: Add proper PIDFILE declarations to init scripts. Replace status_of_proc with a more direct call to pidofproc and simplify the courier and courierfilter init scripts. Closes: #860777. (Note that "simplify" is a bit of an understatement, here. Those init scripts didn't actually work, before. Same applies to the replacement of status_of_proc change.) item 5: Take over the package. Closes #848978. I know this is quite a bunch. And a late one. Please indicate if an unblock of courier-0.76.3-5 is still feasible, if you like me to adjust it or if you prefer to removed courier from stretch, instead. Thank you. Kind Regards Markus Wanner # # All of the changed documented in the changelog. # diff -Nru courier-0.76.3/debian/changelog courier-0.76.3/debian/changelog --- courier-0.76.3/debian/changelog 2016-12-21 15:03:32.0 +0100 +++ courier-0.76.3/debian/changelog 2017-03-27 21:01:13.0 +0200 @@ -1,3 +1,19 @@ +courier (0.76.3-5) UNRELEASED; urgency=medium + + * Fix Debian patch 0012-Define-and-use-PEMFILE-in-mkesmtpdcert.patch: +do not invoke 'install -b' twice from mkesmtpdcert, eliminating +backup files not cleaned up by purge. Closes: #847348. + * Add patch 0026-Fix-TLS-verification-for-CNAMEs.patch: correct TLS +verification when DNS answers with CNAMEs. Closes: #860762. + * Systemd service files: Correct delimiter of dependencies. +Closes: #860765. + * Fix init scripts: Add proper PIDFILE declarations to init scripts. +Replace status_of_proc with a more direct call to pidofproc and +simplify the courier and courierfilter init scripts. Closes: #860777. + * Take over the package. Closes: #848978. + + -- Markus Wanner <mar...@bluegap.ch> Wed, 19 Apr 2017 21:27:14 +0200 + courier (0.76.3-4) unstable; urgency=medium * Orphan the package. # # item 1: Fix Debian patch 0012-Define-and-use-PEMFILE-in-mkesmtpdcert.patch: #do not invoke 'install -b' twice from mkesmtpdcert, eliminating #unnecessary backup files not cleaned up by purge. Closes: #847348. # diff -Nru courier-0.76.3/debian/patches/0012-Define-and-use-PEMFILE-in-mkesmtpdcert.patch courier-0.76.3/debian/patches/0012-Define-and-use-PEMFILE-in-mkesmtpdcert.patch --- courier-0.76.3/debian/patches/0012-Define-and-use-PEMFILE-in-mkesmtpdcert.patch 2016-12-21 15:03:32.0 +0100 +++ courier-0.76.3/debian/patches/0012-Define-and-use-PEMFILE-in-mkesmtpdcert.patch 2017-03-27 21:01:13.0 +0200 @@ -75,7 +75,7 @@ exit 1 } -@@ -34,33 +45,30 @@ umask 077 +@@ -34,33 +45,28 @@ umask 077 BITS="$BITS" set -e @@ -119,9 +119,7 @@ - chown @mailuser@ @mydatadir@/esmtpd.pem - cat esmtpd.key esmtpd.cert >esmtpd.pem - rm -f esmtpd.key esmtpd.cert -+ install -b -m 600 -o "@mailuser@" /dev/null "$PEMFILE" + cat "$KEYFILE" "$CERTFILE" > "$PEMFILE" -+ + rm -f "$KEYFILE" "$CERTFILE" fi diff --git a/libs/imap/mkdhparams.in b/libs/imap/mkdhparams.in # # item 2: Add patch 0026-Fix-TLS-verification-for-CNAMEs.patch: # correct TLS verification when DNS answers with CNAMEs. # Closes: #
Bug#860777: sysv init scripts fail to stop daemons
Package: courier-mta Version: 0.76.1-1 Severity: important Tags: pending Hi, all of the daemons from src:courier-mta cannot be stopped via their sysv init scripts due to $PIDFILE not being set properly. Looking at the git history, this seems broken since the addition of support for non-standard pid file locations (see #822067 as well) and the change to use init-d-script. For the same reason, status doesn't work, either. Installations using systemd are not affected, obviously. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#860765: courier-mta: wrong delimiter in systemd service files
Package: courier-mta Version: 0.75.0-6 Tags: pending Hi, systemd complains it cannot "add dependency on courier-authdaemon.service,courier.service,courierfilter.service, ignoring: Invalid argument". This simply is due to using commas rather than spaces in the service file's Requires and After definitions. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#860762: courier-mta: certificate verification failure for CNAMEs
Package: courier-mta Version: 0.73.1-1.6 Severity: important Tags: fixed-upstream patch pending Hi, as Viktor Szépe recently pointed out to me, courier-mta fails to verify certificates of other MTAs using CNAMEs as their host name. With Amazon SES, Mailjet, etc. this recently became more common and therefore more important to fix. Upstream provides a fix [0] that's easy enough to backport to stretch. I haven't tried jessie, yet. Kind Regards Markus Wanner [0]: Upstream commit: Fix TLS verification when DNS lookup comes back with CNAMEs: https://github.com/svarshavchik/courier-libs/commit/5e522ab14f45c6f4f43c43e32a2f72fbf6354f1c signature.asc Description: OpenPGP digital signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
control: tag -1 -wontfix On 04/10/2017 05:39 PM, Mattia Rizzolo wrote: > On Fri, Mar 10, 2017 at 07:58:52AM -0700, Sean Whitton wrote: > Markus: would you please take this RFS to its end? I'm rather busy with stretch issues I'd like to fix (and then there's the day job as well...) I take it granted there's enough interest to re-introduce fgrun to unstable (without an unblock request, that doesn't affect stretch, and given there's nothing to possibly upgrade in stretch, there's no need for an upload to experimental, only). @Boyuan: could you please: a) change the watch file to point to the github mirror and release tags you found? (Or provide some other way of automatically fetching an orig.tar.gz?) b) commit your changes to alioth / collab-maint (do you have access, there?) c) add yourself as an uploader, I'm happy to review and sponsor uploads of fgrun for you. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#400300: Please add an option or command-line flag to suppress bogus authdaemon warnings
Control: tags -1 +moreinfo Hi, inspecting the code that emits the error "s_connect() failed: Permission denied", it looks like a perfectly reasonable error message. It could probably be more specific in which exact syscall failed, but "permission denied" when trying to connect to authdaemond clearly is an error that should be reported. If you don't mind the error, maybe s_connect shouldn't be called at all? So I'm wondering if this is justs a configuration error. I'd need more information on the setup involving maildrop and courier-authlib. Then again, the code I'm looking at now (0.67.0) is certainly not what it was back then. And maybe the issue got resolved by other means. If I don't hear back on this one within two months, I plan to close the issue. Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#859566: release.debian.org: please let postgis migrate to testing
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney
Dear Release Team,
a fix for postgis is currently not migrating to testing, even though it
got unblocked. AFAIUI this is caused by missing builds on mips and mipsel.
On those architectures, the dependent package sfcgal FTBFSs due to out
of memory errors during compilation. Only sid is affected, though. The
older version of sfcgal in stretch builds just fine even on mips{,el}.
postgis-2.3.1+dfsg-1, i.e. the version just before the fix built fine on
mips{,el}, so I'm fairly confident 2.3.1+dfsg-2 will build perfectly
fine on stretch as well (where sfcgal is available even for those mipsen).
Please help resolving that situation, thanks.
Kind Regards
Markus Wanner
signature.asc
Description: OpenPGP digital signature
Bug#848978: Unsuitable to be part of stable release without proper maintainer
Control: -1 pending Hi, I'm attempting to take over the courier packages and maintain them for stretch. Uploads will follow shortly. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#823807: ITA: courier
Hello Ondřej, On 03/29/2017 08:44 PM, Ondřej Surý wrote: > Feel free and go ahead. I would be most happy if somebody take over and > I have already orphaned the package. thank you for your work on courier. A remaining question: the git repo on alioth/collab-maint is still at 0.76.3-2. Did you simply forget to push 0.76.3-3 and the orphaning? Or shall I commit that to git from the archive? Kind Regards Markus
Bug#858638: unblock: postgis-2.3.1+dfsg-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: Sebastiaan Couwenberg <sebas...@xs4all.nl> Dear release team, please unblock package postgis, it kind of FTBFS [0]: When rebuilding on current stretch, the SQL scripts generated start with an escape character, rather than a backslash. This in turn prevents the postgis extension from being newly created for a database (existing instances would still work). This is due to a bashism in the Makefiles generating the SQL scripts during the build. The additional patch avoid-bashisms.patch fixes that. Kind Regards Markus Wanner [0]: Debian Issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858610 [1]: Original PgApt Issue: https://redmine.postgresql.org/issues/2279 diff -Nru postgis-2.3.1+dfsg/debian/changelog postgis-2.3.1+dfsg/debian/changelog --- postgis-2.3.1+dfsg/debian/changelog 2016-11-29 00:32:50.0 +0100 +++ postgis-2.3.1+dfsg/debian/changelog 2017-03-24 19:35:00.0 +0100 @@ -1,3 +1,10 @@ +postgis (2.3.1+dfsg-2) unstable; urgency=medium + + * Add patch avoid-bashisms.patch to fix the generated sql files. +Closes: #858610. + + -- Markus Wanner <mar...@bluegap.ch> Fri, 24 Mar 2017 19:35:00 +0100 + postgis (2.3.1+dfsg-1) unstable; urgency=medium * New upstream release. diff -Nru postgis-2.3.1+dfsg/debian/patches/avoid-bashisms.patch postgis-2.3.1+dfsg/debian/patches/avoid-bashisms.patch --- postgis-2.3.1+dfsg/debian/patches/avoid-bashisms.patch 1970-01-01 01:00:00.0 +0100 +++ postgis-2.3.1+dfsg/debian/patches/avoid-bashisms.patch 2017-03-24 19:35:00.0 +0100 @@ -0,0 +1,37 @@ +Description: Avoid a few bashisms resulting in invalid SQL files + An echo that's supposed to output a backslash works with bash, but not + in dash. Use printf, instead. +Author: Markus Wanner <mar...@bluegap.ch> +Forwarded: yes, https://lists.osgeo.org/pipermail/postgis-devel/2017-March/026135.html + +--- a/extensions/postgis/Makefile.in b/extensions/postgis/Makefile.in +@@ -39,7 +39,7 @@ + + sql/$(EXTENSION).sql: sql_bits/postgis.sql sql_bits/postgis_comments.sql sql_bits/rtpostgis.sql sql_bits/spatial_ref_sys_config_dump.sql sql_bits/raster_comments.sql sql_bits/spatial_ref_sys.sql + mkdir -p sql +- echo '\echo Use "CREATE EXTENSION $(EXTENSION)" to load this file. \quit' > $@ ++ printf '\\echo Use "CREATE EXTENSION $(EXTENSION)" to load this file. \\quit\n' > $@ + cat $^ >> $@ + + sql/$(EXTENSION)--$(EXTVERSION).sql: sql/$(EXTENSION).sql +@@ -94,7 +94,7 @@ + + #postgis_extension_upgrade_minor.sql is the one that contains both postgis AND raster + sql_bits/postgis_extension_upgrade_minor.sql: ../postgis_extension_helper.sql sql_bits/postgis_upgrade.sql sql_bits/rtpostgis_upgrade.sql ../../doc/raster_comments.sql ../../doc/postgis_comments.sql ../postgis_extension_helper_uninstall.sql +- echo '\echo Use "CREATE EXTENSION $(EXTENSION)" to load this file. \quit' > $@ ++ printf '\\echo Use "CREATE EXTENSION $(EXTENSION)" to load this file. \\quit\n' > $@ + cat $^ >> $@ + + sql_minor_upgrade: sql_bits/postgis_extension_upgrade_minor.sql +--- a/extensions/postgis_sfcgal/Makefile.in b/extensions/postgis_sfcgal/Makefile.in +@@ -74,7 +74,7 @@ + + sql_bits/sfcgal_upgrade_minor.sql: ../postgis_extension_helper.sql sql_bits/sfcgal_upgrade.sql ../../doc/sfcgal_comments.sql ../postgis_extension_helper_uninstall.sql + mkdir -p sql_bits +- echo '\echo Use "CREATE EXTENSION $(EXTENSION)" to load this file. \quit' > $@ ++ printf '\\echo Use "CREATE EXTENSION $(EXTENSION)" to load this file. \\quit\n' > $@ + cat $^ >> $@ + + sql_minor_upgrade: sql_bits/sfcgal_upgrade_minor.sql diff -Nru postgis-2.3.1+dfsg/debian/patches/series postgis-2.3.1+dfsg/debian/patches/series --- postgis-2.3.1+dfsg/debian/patches/series2016-10-21 11:41:00.0 +0200 +++ postgis-2.3.1+dfsg/debian/patches/series2017-03-24 19:35:00.0 +0100 @@ -1,2 +1,3 @@ +avoid-bashisms.patch link-liblwgeom relax-test-timing-constraints.patch signature.asc Description: OpenPGP digital signature
Bug#818377: improve courier-maildrop compatibility
Control: block 822683 by 818377 Hi, I've recently migrated my Courier MTA setup to stretch and had to go through a few hoops to get it to work, again. An important aspect was the courier-maildrop dump. With the packager's hat on, I'm also all for the drop and don't want to re-duplicate sources. This however means I'd like maildrop to handle the courier use case. The good news is: my virtual mail delivery setup via maildrop works if only I enable HAVE_COURIER for my custom-built maildrop package. Reading the sources, it doesn't seem feasible to just enable HAVE_COURIER for the general maildrop build, though. So I'd like to discuss some options that spring to mind: * change HAVE_COURIER into a dynamic flag: this might well have security implications that I'm unaware of. Note, however, that the courier-maildrop was SUID on root, while maildrop only has the SGID bit set for group 'mail'. So courier-maildrop was *more* of a security risk, not less. This could (or should?) possibly be extended by some mechanism that automatically detects whether or not courier is calling the maildrop executable. Extended (or different) behaviour could be prohibited for a non-courier caller. * build two different binaries from the maildrop source, one as it is, the other with HAVE_COURIER enabled. Are there other options? I'm certainly willing to help and hope to find a solution for stretch that fixes the courier use case. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#822683: maildrop: removal of courier-maildrop changed the behaviour
Control: merge 822683 822446 I'm not quite sure how to fix this, yet, but I ran into the very same issue. It seems the difference is not in Debian patches, but depends on the HAVE_COURIER macro. I'll check with the maildrop maintainer. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#858610: generated SQL scripts unusable due to escape characters
Package: postgresql-9.6-postgis-2.3-scripts Version: 2.3.1+dfsg-1 Tags: patch Severity: serious as reported by pgapt user Ludovic Delauné [0] the SQL scripts generated now contain an escape character, breaking CREATE EXTENSION. This affects stretch and sid (w/o pgapt) as well (not jessie, though). It turned out this is due to a bashism in the generation scripts. I've already pushed a fix and pgapt is corrected. Stretch and sid need an upload, too. Kind Regards Markus Wanner [0]: Postgis 2.3.2: bad packaging https://redmine.postgresql.org/issues/2279 signature.asc Description: OpenPGP digital signature
Bug#823807: ITA: courier
Hello Viktor, thanks for the pointers. Please note that upstream development of courier and the Debian packaging for courier are somewhat different projects. You're mostly mentioning upstream work and issues. I guess upstream needs to decide how they want to work. For the Debian packaging, it's certainly going to be the Debian BTS for bug reporting, as it's tightly integrated with all of the existing Debian infrastructure. But I'm subscribed to the relevant courier-* mailing lists [0] and I'll have a look at the bugs and patches you mentioned. Don't expect me to do feature development for courier, though. Kind Regards Markus Wanner [0]: Please note that I'm subscribed to lots of mailing lists, but I'm certainly not reading all of it. Therefore, please CC me for a heads-up. On 03/23/2017 09:59 PM, SZÉPE Viktor wrote: > Would it be possible to enable very easy bug reporting? > I have two here: https://github.com/szepeviktor/courier/issues > > I think discussion in a Debian bug report is quiet hard. > On GitHub it is very easy to contribute. > > Sam merged a lot of Debian patches as you may know. > https://github.com/szepeviktor/courier/commit/bca5316f40bf9335c9ec36db850916481e99cd2c > > And we have final break-through with CNAMEs (Amazon SES, Mailjet etc.) > https://github.com/svarshavchik/courier-libs/commit/5e522ab14f45c6f4f43c43e32a2f72fbf6354f1c > > > And you can read on courier-users that many are willing to contribute. > > All the best to you! > > > SZÉPE Viktor > https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md signature.asc Description: OpenPGP digital signature
Bug#823807: ITA: courier
Hi, as a happy long-time [0] user of courier-mta on Debian [0], I'd like to try my best to make that fine MTA stay in Debian. I'm offering to adopt courier, courier-authlib and courier-unicode. I'd welcome all the help I can get and would love to team up with others, as my spare time is pretty limited. Therefore this call to other fellow courier users: please speak up! Kind Regards Markus Wanner [0]: Just checked my archive: Jun 2003 is the first mail I received with Courier. Must have been on Debian woody. signature.asc Description: OpenPGP digital signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
On 03/08/2017 02:29 PM, Boyuan Yang wrote: > I understand that tarballs are important and could greatly reduce extra works. Well, it's relatively trivial to assemble a tarball. So I think of it more as a sign of upstream's quality awareness (or lack thereof). But well... > Fgrun is really important for flightgear Is it? There's an integrated starter or plane selector, now. And personally, I haven't ever really used fgrun. But that's just a tiny datapoint. Popcon says: 688 installs of flightgear vs 201 of fgrun > and we should not leave it behind, so > I made some investigations. Thanks. > Good news: one of flightgear devs set up a mirror on GitHub and sync every 15 > minutes. If you don't mind using a (frequently synchronized) mirror as > d/watch > upstream, we could switch watch target onto GitHub (with proper tarball > support) and update files in this RFS and/or Alioth Git repo. What do you > think? Yes, that sound's feasible to me. Kind Regards Markus signature.asc Description: OpenPGP digital signature
Bug#857131: [pkg-fgfs-crew] Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
Hello Boyuan, thanks for your efforts. On 03/08/2017 11:53 AM, Boyuan Yang wrote: > * For new d/watch file: I had a hard time making decisions and finally chose > the > sf.net redirector provided by qa.d.o, which points to flightgear *main* > project > tarballs. The lack of an upstream tarball is the main reason I didn't bother to continue to package fgrun. I might be old fashioned, but if upstream doesn't care bundling a tarball, I don't think the software is worth packaging. I kind of allow developers to out-source that task (i.e. to github) and only provide tags. Unfortunately, I didn't find a similar solution with Sourceforge, yet. (It seems it's all there, but uscan would have to be extended to handle Sourceforge.) How did you generate the tarball? For me to sponsor the package (and justify re-introducing it into unstable), I'd at least want a get-orig-source target that automates the process of obtaining a tarball. > Fgrun is now a subproject of flightgear ... ...eh, no more or less than it used to be, before, AFAIUI. > and I really couldn't find a > better page to parse releases or even git tags. Exactly. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#850207: Status of upload?
Hello Tobias, On 01/20/2017 04:06 PM, Dr. Tobias Quathamer wrote: > Any news on this? Another week has passed without an upload. That's not quite correct. I uploaded the last Sunday, but unfortunately something went wrong and I'm unclear what. I asked FTP Masters, but haven't received a response, yet: http://lists.alioth.debian.org/pipermail/pkg-fgfs-crew/2017-January/001828.html > If you do not upload in the next few days, flightgear will *not* be part of > the > next stable release. Thanks for the reminder, I'll try to do what I can to avoid that situation. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#850207: Status of upload?
Dear Tobias, On 01/12/2017 05:42 PM, Dr. Tobias Quathamer wrote: > what's the status of this bug? There's a fix available, are you planning > an upload soon? The package is now marked for autoremoval on February 3, > so there's not much time left. ...I should be able to take care this weekend. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#848114: flightgear: Allows the route manager to overwrite arbitrary files
Control: tags -1 +pending Hello Florent, thanks a lot for your notification and the patch(es). Uploads to stable (security) and unstable should follow, shortly. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#835967: snapshot.debian.org: read errors
Hi, tl;dr: snapshots.debian.org reproducibly truncates around 1-2% of the downloads. While I think that's unusually high, it turns into a real problem in combination with "lazy" clients (or proxies) that do not rigorously check their response. Longer description: I wrote a test script that tries a lot of HTTP GET requests on random resources from snapshot.debian.org, collecting statistics on the responses. Independent of the origin used [0], this reveals the following patterns: 98% - 99.5% of all requests return a good status code and the downloaded body matches in size and by sha1 hash. 0.5% - 1.5% of responses are truncated, i.e. the connection closes before all data is received < 0.5% other errors like 403, 503 or hash mismatches Interestingly, for immediate retries, the distribution changes a lot for the second attempt: 50% - 76%successes 17.6% - 50% truncated responses up to ca. 5% other errors Further retries show a roughly similar success rate, so that eventually, after enough retries, the client gets the expected response. (With deferred retries, giving varnish a chance to populate the cache, the second attempt stats tend a lot towards 100% success, therefore I conclude that the truncation failures are related to cache misses.) Manual inspection of the HTTP response headers from snapshot.debian.org reveals, that varnish is in use (and that somebody there is a Terry Pratchett fan). It seems varnish delivers cached resources with the usual "Content-Length" field in its headers, but uses "Transfer-Encoding: chunked" for cache misses. (Which sounds like an entirely reasonable thing.) But back to the facts: with an additional apt-cache-ng proxy in between, the success rate for follow-up requests drops to nearly 0%. The result distribution for the second attempt then looks more like: 97.4%hash mismatch 1.2% successes 1.2% error 503 For further attempts, these tend towards 100% hash mismatches, because apt-cache-ng stores an invalid (truncated) copy in its cache. I tested chunk transfer encoding of apt-cacher-ng a bit, but since version 0.8.0_pre2-1 of apt-cacher-ng, it seems handle chunking just fine [1]. And I tried to reproduce the error on the varnish side, but without success so far. So I'm not entirely sure where exactly the problem lies, but I am currently suspecting varnish because of two rather vague observations: a) on traffic intercepted between a apt-cacher-ng and varnish, I saw an incorrect resource length advertized by varnish (only once, by manual interception) [2]. I intend to try to reproduce this automatically to test the varnish side. b) a varnish issue that sounds related and got fixed just a couple days ago: https://github.com/varnishcache/varnish-cache/issues/2035 I very much doubt this fix has already made it to the snapshots infrastructure. It certainly didn't arrive in Debian, yet. I cannot proof either of these is really related or the cause of the hash mismatches for the combination with varnish with apt-cacher-ng. Before continuing to investigate, I simply wanted to share my findings. I'd welcome feedback as well as hints about the infrastructure, that might be relevant. I intend to continue analyzing varnish and apt-cacher-ng to be able to eventually solve this issue. Kind Regards Markus Wanner [0]: I tried from 5 different sources with highly varying bandwidth. Most of those are located in Europe, though. And during European daytime. [1]: Chunked transfer encoding seems to work since this commit: commit eebb3c93fd63ceb479b7100f71861069f5b16914 Author: Eduard Bloch <bl...@debian.org> Date: Sat Aug 30 20:33:49 2014 -0700 Fix for premature abort of chunked transfer [2]: The intercepted request on a file weighting 474 KiB: GET /archive/debian/20140818T083621Z/pool/main/libg/libgnomeui/libgnomeui-dev_2.24.5-2_kfreebsd-amd64.deb HTTP/1.1 User-Agent: Debian Apt-Cacher-NG/0.8.0 Host: snapshot.debian.org Range: bytes=122879- Accept: */* Accept-Encoding: identity Connection: keep-alive HTTP/1.1 206 Partial Content Date: Thu, 08 Dec 2016 14:46:21 GMT Server: Apache Expires: Sun, 18 Dec 2016 14:46:21 GMT Cache-Control: public, max-age=864000 ETag: "1aef9a4d688e1e1a0bd09427b894e47fd37413dc" Last-Modified: Mon, 05 Sep 2011 15:23:40 GMT X-Clacks-Overhead: GNU Terry Pratchett Content-Type: application/x-debian-package X-Varnish: 102013332 Age: 0 Via: 1.1 varnish-v4 Transfer-Encoding: chunked Connection: keep-alive Accept-Ranges: bytes Content-Range: bytes 122879-122879/122880 001 . 0 i.e. varnish answered with a chunk of one byte (which may or may not be correct) but a known incorrect value for the complete-range. I certainly wouldn't blame apt-cacher-ng for truncation of the file in that case. signature.asc Description: OpenPGP digital signature
Bug#845156: jessie-pu: package monotone/1.1-4+deb8u2
On 11/21/2016 06:42 PM, Adam D. Barratt wrote: > +monotone (1.1-4+deb8u2) jessie-security; urgency=high > > With the distribution updated to "jessie", please go ahead. Thanks. With that change, I uploaded monotone-1.1-4+deb8u2. Regards Markus signature.asc Description: OpenPGP digital signature
Bug#845156: jessie-pu: package monotone/1.1-4+deb8u2
On 11/21/2016 08:33 AM, Adam D. Barratt wrote: > You uploaded a source package to the security archive, which was then > built. So, no, it's not a binary NMU. It was another Markus (and therefore NMU), but yes, it seems to have been a source-full upload. Please excuse the confusion. > (If it were, there would have been no source upload and the binary > packages would be +something+bX, not +deb8uX.) Understood. Thanks for clarification. Please consider 1.1-4+deb8u2. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
