Bug#993996: RFS: guerillabackup/0.5.0-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, A new version of the package is uploaded at mentors with the following changes compared with the previous version uploaded: * Upstream integration of improvements from Debian RFS review process, see merge on previous version v0.4.0-1: https://salsa.debian.org/halfdog-guest/guerillabackup/-/merge_requests/1 Now I am looking for a sponsor for my package "guerillabackup": * Package name : guerillabackup Version : 0.5.0-1 Upstream contact : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.5.0-1.dsc Changes for the initial release: guerillabackup (0.5.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Bug#993996: RFS: guerillabackup/0.4.0-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name : guerillabackup Version : 0.4.0-1 Upstream contact : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc Changes to the previous version: * Features: * StorageTool: * Added "Size" check policy to detect backups with abnormal size. * Improved messages for interval policy violations and how to fix. * Warn about files not having any applicable policies defined. * Made policy inheritance control more explicit, improved documentation. * Bugfixes: * BackupGenerator: * Fixed invalid executable path in systemd service templates. * Fixed backup generation pipeline race condition on asynchronous shutdown. * Applied pylint. * StorageTool: * Removed anti-file-deletion protection left in code accidentally. * Fixed Interval policy status handling when applying retention policies. * Fixed deletion mark handling with concurrent retention policies. * Fixed exception attempting element retrieval from nonexisting source. * Fixed error message typos. The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.4.0-1.dsc Changes for the initial release: guerillabackup (0.4.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Bug#993996: RFS: guerillabackup/0.3.0-1 [ITP]: Updated package version for ITP, looking for sponsors
Dear mentors, A new version of the package is uploaded at mentors with the following changes compared with the previous version uploaded: * Include upstream support for backup policies checks both for quality (verify interval policy) but also regulatory/GDPR compliant retention policy. * Fixed Debian FHS violation pedantic lintian warning. Now I am looking for a sponsor for my package "guerillabackup": * Package name : guerillabackup Version : 0.3.0-1 Upstream contact : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.3.0-1.dsc Changes for the initial release: guerillabackup (0.3.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Bug#993996: RFS: guerillabackup/0.2.0-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.2.0-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.2.0-1.dsc Changes for the initial release: guerillabackup (0.2.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, hd
Bug#993996: Updated package version for ITP
Reusing old bug report, not opening new one as discussed on IRC. Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.1.1-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.1.1-1.dsc Changes for the initial release: guerillabackup (0.1.1-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- halfdog
Bug#1003768: RFS: guerillabackup/0.1.1-1 [ITP] -- resilient, distributed backup and archiving solution
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.1.1-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.1.1-1.dsc Changes for the initial release: guerillabackup (0.1.1-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- halfdog
Bug#993996: RFS: guerillabackup/0.1.0-1 [ITP] -- resilient, distributed backup and archiving solution
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.1.0-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.1.0-1.dsc Changes for the initial release: guerillabackup (0.1.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Bug#988086: Exim delivery process crashes on each mail with NULL-pointer
Andreas Metzler writes: > On 2021-05-05 Andreas Metzler wrote: [...] >> The breakage is caused by the relevant change in -18/-19 (Pull >> patches to temporarily add an option to turn taint errors >> into warnings.) > > Could you give 4.94.2-2 a spin? It should hit the mirrors in > a couple of hours. I installed it 1h ago, no immediate failure on "exim4 -qff" and local deliveries. Syslogging is also working as expected again. I will update the bug report as soon as another crash would be detected. But for now I deem the bug fixed for me at least. Thanks, hd
Bug#988086: Exim delivery process crashes on each mail with NULL-pointer
Also 4.94.2-1 crashes, e.g. calling "exim4 -qff": (gdb) bt #0 0x55ebf469d87c in log_open_already_exim (name=0x7ffcc589d560 "") at log.c:288 #1 0x55ebf469dadf in log_open_as_exim (name=name@entry=0x7ffcc589d560 "") at log.c:416 #2 0x55ebf469de8d in open_log (fd=fd@entry=0x55ebf476aed0 , type=type@entry=0, tag=tag@entry=0x0) at log.c:552 #3 0x55ebf469e86b in open_logs () at log.c:1512 #4 0x55ebf46f61e8 in appendfile_transport_setup (tblock=0x55ebf675a688, addrlist=, dummy=, uid=, gid=, errmsg=0x55ebf6764908) at appendfile.c:238 #5 0x55ebf466cc6d in deliver_local (addr=addr@entry=0x55ebf6764838, shadowing=shadowing@entry=0) at deliver.c:2322 #6 0x55ebf4677bc9 in do_local_deliveries () at deliver.c:3015 #7 deliver_message (id=id@entry=0x55ebf675ad21 "1ldz84-0001x1-8V", forced=forced@entry=1, give_up=give_up@entry=0) at deliver.c:7209 #8 0x55ebf46a7f9f in queue_run (start_id=start_id@entry=0x0, stop_id=stop_id@entry=0x0, recurse=recurse@entry=0) at queue.c:662 #9 0x55ebf465aac9 in main (argc=2, cargv=) at exim.c:4715
Bug#988086: Exim delivery process crashes on each mail with NULL-pointer
Adam D. Barratt writes: > On Wed, 2021-05-05 at 11:07 +0000, halfdog wrote: >> This is weird: I have only bullseye/bullseye-updates/bullseye- >> security >> in my sources list. I applied all updates on 2nd of May with >> no Exim package available. Then after the 21nails disclosure >> I run the updates (timestamps in UTC): >> >> 2021-05-02 07:05:31 status installed initramfs-tools:all 0.140 >> ... >> 2021-05-04 16:49:48 upgrade exim4-daemon-light:amd64 4.94-17 4.94-19 >> >> But there is no transaction for 4.94-19 in PTS between these >> two dates, next is > > >> [2021-05-05] exim4 4.94-19 MIGRATED to testing (Debian testing >> watch) > > The "testing watch" script only runs daily, in the early morning UTC. > The 4.94-19 package actually migrated on the morning of the 4th (again > UTC): > > 20210504101451|control-suite|dak|added|testing|exim4 4.94-19 source > > The upload including the 21nails fixes is: > > 20210504134823|process-upload|dak|ACCEPT|exim4_4.94.2-1_multi.changes Thanks, that explains the timeline. I am now at ii exim4-daemon-light4.94.2-1 amd64 lightweight Exim MTA (v4) daemon At least it does not segfault on locally generated messages as the 4.94-19 package did. What a weird coincidence that the 4.94-19 seemed to crash exactly around that part of code that seemed to related to CVE-2020-28007. Regards, hd
Bug#988086: Exim delivery process crashes on each mail with NULL-pointer
This is weird: I have only bullseye/bullseye-updates/bullseye-security in my sources list. I applied all updates on 2nd of May with no Exim package available. Then after the 21nails disclosure I run the updates (timestamps in UTC): 2021-05-02 07:05:31 status installed initramfs-tools:all 0.140 ... 2021-05-04 16:49:48 upgrade exim4-daemon-light:amd64 4.94-17 4.94-19 But there is no transaction for 4.94-19 in PTS between these two dates, next is [2021-05-05] exim4 4.94-19 MIGRATED to testing (Debian testing watch)
Bug#988086: Exim delivery process crashes on each mail with NULL-pointer
Salvatore Bonaccorso writes: > Hi, > > On Wed, May 05, 2021 at 06:58:02AM +, halfdog wrote: >> Package: exim4-daemon-light >> Version: 4.94-19 >> Severity: grave >> >> Yesterdays 21nails update causes Exim to fail delivery of any >> messages. This might be related to using syslogging only without >> any file logging configured: >> ... > > Just to doubly-confirm, you see the problem only after yesterday's > update, but not yet in 4.94-19 as reported, right? Just to avoid > potential confusion. I see the problems with ii exim4-daemon-light4.94-19amd64 lightweight Exim MTA (v4) daemon I checked the PTS and it seems, that this package might have just been released around the same time (no timestamp given) than the 21nails patches. [2021-04-26] Accepted exim4 4.94-19 (source) into unstable (Andreas Metzler) [2021-05-05] exim4 4.94-19 MIGRATED to testing (Debian testing watch) I did not verify if exim4-daemon-light for bullseye is REALLY patched or still vulnerable, which it should be (unless Debian has broken the disclosure embargo).
Bug#988086: Exim delivery process crashes on each mail with NULL-pointer
Package: exim4-daemon-light Version: 4.94-19 Severity: grave Yesterdays 21nails update causes Exim to fail delivery of any messages. This might be related to using syslogging only without any file logging configured: Core was generated by `/usr/sbin/exim4 -Mc 1ldzSC-0001yw-RY'. Program terminated with signal SIGSEGV, Segmentation fault. (gdb) bt #0 0x5594e218a364 in log_create (name=0x7ffe89730380 "") at log.c:283 #1 0x5594e218a4a6 in log_create_as_exim ( name=name@entry=0x7ffe89730380 "") at log.c:336 #2 0x5594e218aa20 in open_log (fd=fd@entry=0x5594e2256ed0 , type=type@entry=0, tag=tag@entry=0x0) at log.c:489 #3 0x5594e218b17b in open_logs () at log.c:1451 #4 0x5594e21e1ed8 in appendfile_transport_setup (tblock=0x5594e2430688, addrlist=, dummy=, uid=, gid=, errmsg=0x5594e243a200) at appendfile.c:238 #5 0x5594e21596ad in deliver_local (addr=addr@entry=0x5594e243a130, shadowing=shadowing@entry=0) at deliver.c:2322 #6 0x5594e21645f9 in do_local_deliveries () at deliver.c:3015 #7 deliver_message (id=, forced=forced@entry=0, give_up=give_up@entry=0) at deliver.c:7209 #8 0x5594e21456a3 in main (argc=3, cargv=) at exim.c:4644 0x5594e218a355 <+101>: call 0x5594e2140bc0 0x5594e218a35a <+106>: xor%ecx,%ecx 0x5594e218a35c <+108>: mov$0x1e8,%edx 0x5594e218a361 <+113>: mov%rbp,%rsi => 0x5594e218a364 <+116>: movb $0x0,(%rax) 0x5594e218a367 <+119>: xor%edi,%edi 0x5594e218a369 <+121>: mov%rax,%r13 0x5594e218a36c <+124>: call 0x5594e21667e0 rax0x0 0
Bug#973340: RFS: guerillabackup/0.0.2-1 [ITP] -- resilient, distributed backup and archiving solution
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "guerillabackup": * Package name: guerillabackup Version : 0.0.2-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.2-1.dsc Changes for the initial release: guerillabackup (0.0.2-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, hd PS: I tried to address the hints from previous RFS for older version (see https://bugs.debian.org/849754) or from private mails, e.g. Miroslav Kravec (documentation improvements needed), various comments on mentors list/irc (regarding salsa, gbp use, debian-file changes).
Bug#973304: debsign environment variable handling broken
Adam D. Barratt writes: > On Wed, 2020-10-28 at 15:03 +0000, halfdog wrote: > > According to Debian Bullseye manpage "debsign" should handle the > > "DEBSIGN_PROGRAM" environment variable as follows: > > > >DEBSIGN_PROGRAM > > Setting this is equivalent to giving a -p option. > > Well... not really. > > The sentences just before that quote say (emphasis mine): > > "The two configuration files /etc/devscripts.conf and ~/.devscripts are > sourced in that order to set configuration variables. Command line > options can be used to override configuration file settings. > **Environment variable settings are ignored for this purpose.** The > currently recognised variables are: " > > So debsign ignoring the setting of that variable in the environment is > behaving precisely as documented. This is common across almost all > variables for almost all tools in devscripts. > > Regards, > > Adam Sorry, my fault. I did wishful, sloppy reading, hoping that environment variables only cannot override settings already in the devscripts.conf instead of every time. The reason why I was trying the most obscure ways to change the gpg program is, that there seems no way to create a "gbp buildpackage" command line, that changes DEBSIGN_PROGRAM without the need to have root privileges. "gbp buildpackage" calls "debbuild" with controllable arguments (via "--git-builder" option". Is there any way known to influence "debsign" via "debuild" command line arguments without touching the file system?
Bug#973304: debsign environment variable handling broken
Package: devscripts
Version: 2.20.4
Severity: normal
According to Debian Bullseye manpage "debsign" should handle the
"DEBSIGN_PROGRAM" environment variable as follows:
DEBSIGN_PROGRAM
Setting this is equivalent to giving a -p option.
The "-p" should replace the gpg program:
-pprogname
When debsign needs to execute GPG to sign it will run progname
(searching the PATH if necessary), instead of gpg.
When invoking
21086 execve("/usr/bin/debsign", ["debsign",
"guerillabackup_0.0.2-1_amd64.changes"], ["LC_CTYPE=C.UTF-8", "TERM=screen",
"DEBSIGN_PROGRAM=/usr/bin/gpg-alt", ... ]) = 0
It will truncate the environment variable when invoking other binaries:
21090 execve("/usr/bin/egrep", ["egrep", "^(DEBSIGN|DEBRELEASE|DEVSCRIPTS)_"],
[""DEBSIGN_PROGRAM=", "DEB_BUILD_GNU_TYPE=x86_64-linux-gnu", ...
debsign will then fork twice:
21086 clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f2b53791850) = 21120
21120 clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f2b53791850) = 21121
before calling the wrong gpg executable to get version and later on
for signing:
21121 execve("/usr/bin/gpg", ["gpg", "--version"],
["DEB_HOST_GNU_SYSTEM=linux-gnu", "DEB_BUILD_ARCH_BITS=64", ...
"DEBSIGN_PROGRAM=", "DEB_BUILD_GNU_TYPE=x86_64-linux-gnu", ...]) = 0
Bug#968354: xpdf crash with empty document
Package: xpdf
Version: 3.04-13
Severity: normal
Tag: security
On Debian Bullseye this crashes xpdf with coredump:
touch x.pdf; xpdf x.pdf
Funny, after a 2-byte Virtualbox (and now qemu) crash, this is
the shortest input for a DoS-bug I have seen so far :-)
For xpdf this bug itself is not really a security risk: an attacker
could also send a white page document or no document at all if
he wants the victim not to see a document. Still someone familiar
with the code should look at it, maybe some half-broken document
could turn the NULL-dereference into something more useful.
rax0x0 0
0x5556e6d0 <+16>:je 0x5556e6e0
0x5556e6d2 <+18>:mov%ebp,%eax
0x5556e6d4 <+20>:pop%rbx
0x5556e6d5 <+21>:pop%rbp
0x5556e6d6 <+22>:pop%r12
0x5556e6d8 <+24>:retq
0x5556e6d9 <+25>:nopl 0x0(%rax)
0x5556e6e0 <+32>:mov0x8(%rbx),%rax
=> 0x5556e6e4 <+36>:mov(%rax),%rax (doc is null)
0x5556e6e7 <+39>:mov(%rax),%rdi
0x5556e6ea <+42>:callq 0x5557d730
Relevant source:
int XPDFCore::loadFile(const GString *fileName, GString *ownerPassword,
GString *userPassword) {
int err;
err = PDFCore::loadFile(fileName, ownerPassword, userPassword);
if (err == errNone) {
// save the modification time
modTime = getModTime(doc->getFileName()->getCString());
// update the parent window
if (updateCbk) {
(*updateCbk)(updateCbkData, doc->getFileName(), -1,
doc->getNumPages(), NULL);
}
}
return err;
}
(gdb) print doc
$1 = (PDFDoc *) 0x0
If understand correctly, "PDFCore::loadFile" does not return
an error when processing an empty file, but also does not set
static variable "doc". This seems to be due to "xpdf/PDFCore.cc":
int PDFCore::loadFile2(PDFDoc *newDoc) {
int err;
double w, h, t;
int i;
// open the PDF file
if (!newDoc->isOk()) {
err = newDoc->getErrorCode();
delete newDoc;
return err;
}
...
The PDFDoc seems to come from "libpoppler.so.82" already and
detects the problem:
Syntax Error: Document stream is empty
On a quick glance I could not see this may result in !isOk()
but also "err" not set correctly. If error should be in libpoppler,
then this is the relevant version:
ii libpoppler82:amd64 0.71.0-6
amd64PDF rendering library
Bug#951102: iptables-restore empty line not accepted any more (regression)
Package: iptables Version: 1.8.4-2 Severity: grave Tags: security After upgrading from "1.8.3-2", iptables-restore handles empty lines differently and does not restore the rules. Thus old rulesets stored with save and then annotated for better readability (to avoid loads of "iptables -A" calls), do not load any more. As firewall data is ignored, this might break network access to machines or have unknown security impact on the current firewall ruleset. # iptables-restore --noflush < *nat > > -A POSTROUTING -s 10.0.0.0/16 -o usb0 -j SNAT --to-source 192.168.0.1 > COMMIT > *filter > > -A INPUT -p tcp -m tcp --dport 22 -j DROP > COMMIT > EOF iptables-restore: COMMIT expected at line 2 # iptables-restore --noflush < *nat > -A POSTROUTING -s 10.0.0.0/16 -o usb0 -j SNAT --to-source 192.168.0.1 > COMMIT > *filter > > -A INPUT -p tcp -m tcp --dport 22 -j DROP > COMMIT > EOF iptables-restore: COMMIT expected at line 5
Bug#849714: RFS: guerillabackup/1.0-1 [ITP] -- resilient, distributed backup and archiving solution
Dear mentors, I am looking for a sponsor for my package "guerillabackup". I have updated the Salsa repository to build on Debian Bullseye also removing mentors.debian.net lintian warnings on old versions. I have tested the package on Bullseye machines. * Package name: guerillabackup Version : 0.0.1-1 Upstream Author : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.1-1.dsc Changes since the last upload: * Initial packaging of guerillabackup (Closes: #849714) Regards, hd
Bug#849714: gbp-buildpackage test
Rebuilt package to see the gbp/salsa still works on Debian Buster build host, uploaded to mentors.
Bug#849714: gbp-buildpackage test
Rebuilt package to see the gbp/salsa still works on Debian Buster build host, uploaded to mentors.
Bug#849714: gbp-buildpackage test after mentors.debian.net upgreade
Rebuilt package to see the gbp/salsa still works on Debian Buster build host and after "mentors.debian.net upgraded to buster" [0]. [0] https://lists.debian.org/debian-mentors/2019/04/msg00116.html
Bug#849714: gbp-buildpackage test
Rebuilt package to see the gbp/salsa still works on Debian Buster build host, uploaded to mentors. ~
Bug#849714: Mentors test upload
Rebuilt package to see the gbp/salsa still works on Debian Buster build host, uploaded to mentors.
Bug#922652: Strange bug tracker error maybe related to lone dot
Package: bugs.debian.org Running a data deduplication tool on all sent and received messages detected an anomaly regarding a message from bugs.debian.org dating back to 2018-01-22. The exact cause is unknown but might be related to a lone "." in a message truncating it. It is also unclear which component caused the error - the bug tracker or some other component involved. This bug is for documentation and to attempt reproducing the issue. Otherwise this bug can be closed. LAST-LINE-BEFORE-DOT . FIRST-LINE-AFTER-DOT
Bug#849754: Processed: RFS: guerillabackup/0.0.1-1 [ITP]
Hi, Debian Bug Tracking System writes: > Processing commands for cont...@bugs.debian.org: > > > retitle 849754 RFS: guerillabackup/0.0.1-1 [ITP] > Bug #849754 [sponsorship-requests] RFS: guerillabackup/0.0.1-1/0.0.1-1 [ITP] > Changed Bug title to 'RFS: guerillabackup/0.0.1-1 [ITP]' from 'RFS: > guerillabackup/0.0.1-1/0.0.1-1 [ITP]'. Thanks for correcting this one, seems I have misunderstood the documentation regarding bug naming. I uploaded a new test-build of the package to https://mentors.debian.net/package/guerillabackup to verify, that gbp/salsa-build still works and no new lintian errors/warnings due to new rules are reported. *** CAVEAT on sponsoring: I detected by chance, that outbound messages from bugs.debian.org were corrupted under some conditions, affecting some part of the mentoring/sponsorship communication process. If due to greylisting someone happened to read message from the bug tracker before receiving the message addressed directly (quite likely), the content of the message might have been largely truncated, thus looking like being an incomplete answer to mentor feedback. While the messages sent out from bugs.debian.org were corrupted, the bug tracker web interface will show the complete, unmodified message initially sent. If you were wondering about my strange replies, please check https://bugs.debian.org/849714 https://bugs.debian.org/849754 Sorry about the inconvenience! hd
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Michael Tokarev writes: > 13.01.2019 0:46, halfdog wrote: > > Michael Tokarev writes: > [] > >> There's no need to explicitly enable gtk/sdl display, it is the > >> default if the system has all the necessary packages installed > >> and if X environment is available. > > > > I see. After upgrading the Stretch nonrequired/nonexisting? package > > qemu-system-gui was not installed on Buster, so I installed it > > manually and forced the qemu call options as sugessted in forum > > posts by people having similar issues. > > qemu-system-gui is a recommended package. Usually and by default, > apt installs recommended packages. These are not installed only if > you explicitly disable this, by adding APT::Install-Recommends=0 > to /etc/apt.conf. But this is explicitly warned against, ... > > The large amount of deps for qemu-system-gui is the exact reason > why this whole thing popped out, ... I know that and REALLY appreciate the current behaviour! "Recommends" gives normal users good default setups, that work (but might be large, slow or security risks). Disabling "Recommends" just makes me search forums once each time packages change their "package ABI", but afterwards the automated installs will do exactly the right thing, depending on headless or graphical desktop configuration. > ... > >> Do you use USB Tablet device for guest (which syncronizes host and > >> guest mouse pointer)? > > > > No, it is enabled as all USB features are disabled for security > > reasons. > > Please try it with -usb -usbdevice tablet to see whenever it fixes > your issues. I tried it. With that device the pointer is invisible with both [Grab]-[Fullscreen] and [FS]-[Grab] control sequence. > >> Does the same erratic behavour occurs with other vga variants, > >> like std? > > > > I tried "-vga std" but it seems, that this one is completely broken > > when you have a non-standard real-hardware display size and want to > > use a guest display covering the full host-hardware-display in > > fullscreen mode (no pixel-rot on a quite small "1366x768" display). > > Yes that's lovely thing, stdvga only knows about standard VGA > sizes where the key point is that amount of horizontal dots must > be dividable by 8, so each display line ends on whole byte. Thanks for that hint! I guess wasting 6 horizontal pixels would be completely OK, so running guest on "1360x768" might be another workaround. > I don't > know where this 1366 come from but it was quite often requested > size and it really does not work... I do not know why Lenovo selected that size for all the small size Thinkpads, but it is really convenient :-) > BTW, I didn't know about -vga virtio, the first time I come across > it is this your bugreport. And yes this exact thing is done differently > in virtio vga, in a way which is incompatible with old VESA/VGA > interface (in particular there's no BitBLT operations there which > are mandated by VESA standard - that's the main reason why the > horisontal size should be dividable by 8, for bitblt to work right). Ah, that was helpful to locate more information, e.g. http://qemu.11.n7.nabble.com/Can-t-see-mouse-cursor-on-VNC-viewer-td612906.html When reconfiguring the server to use Section "Device" Option "SWcursor" "True" Identifier "Card0" ... the sequence [Grab]-[Fullscreen] restores the old sdl behaviour, which seems to be the best (and even an acceptable workaround) so far. This works both with and without the "usb tablet". As automated setup creates a stripped down, hardened X config anyway, adding this option is no real burden. It would be interesting to know, why the "hardware-cursor" is not displayed by the host gtk interface - maybe the graphics card on the host requires similar "hardware-cursor" support for that? Strange that completely identical X configuration worked with sdl. BTW why I wanted to switch std -> virtio: I would hope, that the attack surface of specialized virtual hardware is smaller as it does not have to "fake" 20 years of BIOS/bus/hardware specifics, which may all contain exploitable bugs. > ... > > With "-vga std" the mouse positioning and display seems to work > > both in window and full-screen mode (as far as I can guess from > > the reproducible/stable bute quite distorted graphics output). > > So it is still distorted... Maybe not, if I try to apply your modulo(8) trick (after others). > []>> Here I don't understand. Are your mobile screen SMALLER than the > >> guest screen, so that qemu has to scale DOWN? > > > > Yes, it is
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Michael Tokarev writes: > 12.01.2019 14:51, halfdog wrote: > > Package: qemu-system-gui > > Version: 1:3.1+dfsg-2 > > > > After upgrading from Debian Stretch to Buster, thus changing > > the qemu version on host, "-display gtk" has to be used instead > > of "sdl" as the later is not available with Buster any more. > > There's no need to explicitly enable gtk/sdl display, it is the > default if the system has all the necessary packages installed > and if X environment is available. I see. After upgrading the Stretch nonrequired/nonexisting? package qemu-system-gui was not installed on Buster, so I installed it manually and forced the qemu call options as sugessted in forum posts by people having similar issues. I guess this might be related to running quite minimalistic window manager configurations, like mine requiring just ~25MB memory compared to the multi-100MB full-blown ones. Installing the "qemu-system-gui" even triggered gtk-base library installation as thay are not needed by anything else it seems. > > Since that switch the mouse behaviour changed, making guest machines > > (also Debian Buster) very hard to use. I do not know the old > > Stretch behaviour with "gtk" interface as I never used it. > > I don't remember already if gtk interface has been available in > stretch, I think I tried to switch to gtk but rolled it back at > some time. In previous version of qemu as has been available in > Debian (in buster), gtk interface had a lot of issues (that's why > I had to revert back to sdl, and did that at least twice). > > Current 3.1 gtk is quite stable finally, and it is the default > upstream too. That's why, I would like to switch so that the old sdl stuff can be abandoned to save open source developers time. But therefore I have to get it working beforehand. > > Reproduce: Run a qemu instance with "-vga virtio" and "-display > > gtk". Maybe the window manager is relevant also, using fvwm2 > > with an EdgeScroll configuration on host/guest shows the problematic > > behaviour. There are no specific guest additions installed in > > the guest nor acceleration in place. > > So guest is linux too? What's "EdgeScroll"? That is a window manager behaviour, where you let's say have 9 virtual desktops (3x3) and each one can hold windows. By moving the mouse on screen (1,1) to the right edige of the desktop, the window manager will switch to screen (1,2). Also the mouse pointer placement is adjusted, e.g. assuming a 800x600 screen, visible mouse position would change e.g. (300,580) -> (310,599) -> (315,5). > Do you use USB Tablet device for guest (which syncronizes host and > guest mouse pointer)? No, it is enabled as all USB features are disabled for security reasons. > Does the same erratic behavour occurs with other vga variants, > like std? I tried "-vga std" but it seems, that this one is completely broken when you have a non-standard real-hardware display size and want to use a guest display covering the full host-hardware-display in fullscreen mode (no pixel-rot on a quite small "1366x768" display). With "-vga std" the mouse positioning and display seems to work both in window and full-screen mode (as far as I can guess from the reproducible/stable bute quite distorted graphics output). > > Following options exist for still using the mouse/vm: > > > > a) Using "Grab input" and "fullscreen", the mouse position is > > correct, but one cannot see any guest mouse pointer. Only changes > > in hilighting or menu popups (when clicking) indicate the current > > mouse position. > > > > b) Using "fullscreen" and then "grab input" does show the mouse > > pointer but mouse position near the screen edge is not submitted > > to the guest, those events seem to be consumed on host before that. > > Thus those mouse positions cannot be reached in the guest window. > > > > c) Not using fullscreen: fonts are harder to read due to scaling > > on quite small mobile display (that's why the fullscreen preference > > to avoid pixel-rot). The mouse pointer is shown and edge detection > > would work theoretically, but it usually should happen in some > > undistinguishable area where the guest-screen-background color > > changes to the same color gtk-window-background, thus it is very > > hard to hit it with the pointer. > > Here I don't understand. Are your mobile screen SMALLER than the > guest screen, so that qemu has to scale DOWN? Yes, it is smaller, when not in full-screen mode: both screens (real hardware and virutal screen) have exactly the same size. When not in full screen mode, the top/bottom part of the GTK window reduces the usable real-screen size about 10%, thus the guest screen content has to be scaled down by 10$. > ... Thanks for your great committment to Debian package quality! hd
Bug#919116: Detaching a tab breaks keyboard input
Package: qemu-system-gui Version: 1:3.1+dfsg-2 When running a Qemu machine with "-display gtk" then selecting Menu-bar -> View -> Detach tab and closing the detached window (thus reattaching it to the base GTK window), then everything looks nice afterwards but keybord events are not forwarded to the guest any more (mouse is still working). There is no difference in behaviour when GTK window is scaling the guest screen, guest display is in full screen mode or not, input is grabbed. Using the qemu monitor (with "-monitor stdio") still transports the keystrokes, so the guest seems to be working still. (qemu) sendkey x (qemu) sendkey ret
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Package: qemu-system-gui Version: 1:3.1+dfsg-2 After upgrading from Debian Stretch to Buster, thus changing the qemu version on host, "-display gtk" has to be used instead of "sdl" as the later is not available with Buster any more. Since that switch the mouse behaviour changed, making guest machines (also Debian Buster) very hard to use. I do not know the old Stretch behaviour with "gtk" interface as I never used it. Reproduce: Run a qemu instance with "-vga virtio" and "-display gtk". Maybe the window manager is relevant also, using fvwm2 with an EdgeScroll configuration on host/guest shows the problematic behaviour. There are no specific guest additions installed in the guest nor acceleration in place. Following options exist for still using the mouse/vm: a) Using "Grab input" and "fullscreen", the mouse position is correct, but one cannot see any guest mouse pointer. Only changes in hilighting or menu popups (when clicking) indicate the current mouse position. b) Using "fullscreen" and then "grab input" does show the mouse pointer but mouse position near the screen edge is not submitted to the guest, those events seem to be consumed on host before that. Thus those mouse positions cannot be reached in the guest window. c) Not using fullscreen: fonts are harder to read due to scaling on quite small mobile display (that's why the fullscreen preference to avoid pixel-rot). The mouse pointer is shown and edge detection would work theoretically, but it usually should happen in some undistinguishable area where the guest-screen-background color changes to the same color gtk-window-background, thus it is very hard to hit it with the pointer. So essentially one can decide beween working mouse cursor display or working mouse pointer position, but you cannot have both. The current workaround is to switch between a) and b) requiring 8 multi-key strokes and one mouse gesture instead of having just to move the mouse pointer to the edge of the screen (old behaviour with sdl).
Bug#919056: Detaching a tab renders fullscreen mode useless
Package: qemu-system-gui Version: 1:3.1+dfsg-2 When running a Qemu machine with "-display gtk" then selecting Menu-bar -> View -> Detach tab and Menu-bar -> View -> Fullscreen will then display the menu bar into fullscreen mode, not the virtual machine window.
Bug#919055: qemu aborts on calling migrate twice
Package: qemu-system-x86 Version: 1:3.1+dfsg-2 Invoking migrate twice (accidentially) will cause QEMU to abort and current virtual machine state is lost. Reproduce: Start qemu with monitor enabled, e.g. "-monitor stdio". Stop the machine and invoke migrate twice: (qemu) stop (qemu) migrate "exec:cat > /dev/null" (qemu) migrate "exec:cat > /dev/null" qemu-system-i386: /build/qemu-CGHs6D/qemu-3.1+dfsg/block.c:4647: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. Aborted (core dumped) Expected behavior: Sucessfully write a second migration dump or refuse to do so.
Bug#917331: nmh message include via POP3 ignores password (null pointer?)
Package: nmh Version: 1.7.1-2+deb8u1 Severity: serious No matter which password is entered, inc will always send the password string "(null)" to the server, thus failing authentication. It is easily reproducible on fresh installs: First emulate a POP3 server using socat: $ socat TCP4-LISTEN:,reuseaddr=1,bind=127.0.0.1 - Initialize nmh: /usr/bin/mh/install-mh Run the include program: /usr/bin/mh/inc -host 127.0.0.1 -user test -port While inc is running, switch to the "socat" process and enter single lines so that "socat" data looks like that: +OK POP3 service ready USER test +OK PASS (null) No matter which password was used, always "PASS (null)" is sent to server.
Bug#849714: ITP: guerillabackup: packaging v0.0.1
Version v0.0.0 as indicated in initial ITP is obsolete. As discussed on #debian-mentors IRC, continuing with the same ITP bug should be OK. Packaging data was moved to salsa, gbp seems to work without problems. To build and review the package, following commands work: gbp clone --debian-branch debian/sid --upstream-branch upstream https://salsa.debian.org/halfdog-guest/guerillabackup.git cd guerillabackup git config user.email "your mail" git config user.name "your name" git checkout debian/sid gbp buildpackage --git-pbuilder --git-pbuilder-options=--source-only-changes --unsigned-source --unsigned-changes
Bug#849754: RFS: guerillabackup - new upstream version
Version v0.0.0 as indicated in initial RFS is obsolete. As discussed on #debian-mentors IRC, the related ITP bug can be reused for v0.0.1. What about the RFS? Close it or retitle it? Debian packaging data was moved to salsa, hopefully integrating all review recommendations from above. gbp seems to work now without problems. To build and review the package, following commands work: gbp clone --debian-branch debian/sid --upstream-branch upstream https://salsa.debian.org/halfdog-guest/guerillabackup.git cd guerillabackup git config user.email "your mail" git config user.name "your name" git checkout debian/sid gbp buildpackage --git-pbuilder --git-pbuilder-options=--source-only-changes --unsigned-source --unsigned-changes
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello Gianfranco, Gianfranco Costamagna writes: > control: owner -1 ! > control: tags -1 moreinfo > Hello, > > >I am looking for a sponsor for my package "guerillabackup" > > I would really like to see the package working, but I see the > upstream repo is lacking the history, this makes the Debian > work less efficient in cherrypicking new stuff. > Two commits are really not that much, seems like an inactive project. Well, one commit (the first one is the github creation commit). The software is the Python2 port of a quite old project, so just rewriting it, comparing result with old program by unit tests and committing the result to github resulted in a single commit. All other changes are from the request to transform it to Python3 (some earlier review), fixes for problems introduced by that changes, which were then added as a diff for packaging the initial release version If it would help, I could move those changes from my local branch (which is used to create the patches for the Debian package by comparing it to the github trunk) also to the github trunk. This would then create a new github trunk (upstream) version, thus starting a new RFS process I guess (due to version change). Then there would also be more upstream commits. > Is it the case? Yes and no: it is working on all my machines without any flaws or major changes for more than a year or so now and as long as I do not change my setup to expose new bugs (which I do not plan to do) or someone else reports bugs from his setup (which would require solid packaging to have new users), so long there is no real need for further development. While the RFS was running, all changes went to the Debian packaging repository and now the new salsa repository, which should build the package using "gbp", hence also no upstream changes. But I did not manage to get gbp running from the documentation, e.g. trying the following did not work out and the various (sometimes contradictory) recommendations from IRC did not really improve the situation. You can test with: git clone https://salsa.debian.org/halfdog-guest/guerillabackup.git cd guerillabackup git config user.email "m...@halfdog.net" git config user.name "halfdog" gbp buildpackage So I stopped trying with salsa/gbp. Maybe in some years when alioth/ salsa transition has progressed, documentation will be more conclusive for packaging noobs and make that step easier. > Please note: I maintain borgbackup, that I think is really more > powerful (complete) than your tool (please have a look at it). Now I had time to check that one out. If I understand correctly, it could be a nice preprocessor for the guerillabackup: * borgbackup: does local file deduplication, uses nearby storages (similar trust zone, high bandwidth, reliable connections) to create repository with or without symmetric encryption * guerillabackup: performs assymetric encryption of borgbackup outputs (e.g. the borgbackup repositories or changesets exported from the repository), distribution of redundant copies of those outputs to remote cloud storage with lower trust (other trust zones, low bandwith, unreliable connections) hd
Bug#888604: util-linux mount/unmount ASLR bypass via environment variable
Package: mount Version: 2.29.2-1 Severity: normal Tags: security Debugging of libmount can be activated, also in SUID binaries, thus spilling out the heap addresses. Note that "CXT" structure contains function pointers to overwrite. Test: LIBMOUNT_DEBUG=all /bin/umount / Output: 2401: libmount: CXT: [0x562d3abb0760]: > allocate [RESTRICTED] 2401: libmount: CXT: [0x562d3abb0760]: umount: / 2401: libmount: CXT: [0x562d3abb0760]: umount: lookup FS for '/' 2401: libmount: CXT: [0x562d3abb0760]: checking for writable tab files 2401: libmount:UTILS: utab: /run/mount/utab 2401: libmount:CACHE: [0x562d3abb1950]: alloc 2401: libmount:CACHE: [0x562d3abb1950]: canonicalize path / 2401: libmount:CACHE: [0x562d3abb1950]: add entry [ 1] (path): /: / 2401: libmount: CXT: [0x562d3abb0760]: tabfilter ENABLED! 2401: libmount: TAB: [0x562d3abb35b0]: alloc ... The output can easily be used by creating a local domain socket with only 4k buffer size, filling it up until writes are blocking and then start umount with that socket as stdout. This allows race-free reading of the address output before umount accesses other user-controlled resource. Thus any error during the downstream procedure creating some kind of write-where vulnerability will always find the correct target. See also: * https://www.spinics.net/lists/util-linux-ng/msg14978.html * https://bugzilla.redhat.com/show_bug.cgi?id=1534076
Bug#849754: guerillabackup review
Hello Michael, Thanks for you detailed review. Michael Lustfield wrote: > I reviewed this packaging and came up with some issues: > > - The description does nothing to explain what makes this solution unique. > + Why is this special? > + How does it even work? > + This should be easily gleaned from the package description. This is the current description for reference. There is similar topic at the end of the mail, where improvements are discussed in detail. === The tool supports asynchronous, local-coordinated, distributed secure backup generation, forwarding, verification, storage and deletion even in rugged environments. The system is open to integration of own code. The codebase is very small and kept simple to ease auditing. . Unlike business backup solutions, guerillabackup also considers following conditions that might be encountered with private use: * infrastructure uptime below 99%, e.g. machines not always powered * poor network connectivity, e.g. mobile access, parallel video streaming * poor physical access and anti-theft protection of machines * no security monitoring of machines . See /usr/share/doc/guerillabackup/Design.txt.gz section "Requirements" for more information. === > - There is a lintian override for a legitimate mistake (unindented list). Could you please point out the legitimate mistake? The 4 bullet points above form a list. If you remove them, lintian will not complain any more. > - d/patches is scary... > + Do not create lintian overrides using d/patches. Where should they be put instead? > + Keep patches to essential changes (not syntax and language changes). > + Do not perform such a massive application rewrite using d/patches. The size of patches is mostly due to a previous review arguing for Python2 to Python3 change. As the upstream version IS written in Python2 and I cannot change the past, those changes are applied as patch. As the changes are very intrusive, they affect nearly all files, thus the patch is generated automatically. I know, that this intermediate state is not nice. If the package is accepted, the next upstream version will include them already and thus the patches will not require them any more - acceptance will shape the development goals of upstream. As long as no acceptance can be reached, I do not want to change/branch upstream in each direction the contraticting review comments suggest, thus creating a large mess of parallel versions. > + That change should be sent upstream... not held local. They will go upstream, as soon as it is clear, that they are needed. Without moving towards acceptance of the packet, the changes are definitely not needed by anyone. Downstream shapes upstream and vice versa. > - Absolutely DO NOT generate lintian-override files from d/patches. Where should they be put instead? Would this be the correct solution? * Put them in d/guerillabackup.lintian-overrides * Change d/rules somehow, so that "dh_lintian" is called automatically? > - d/control should wrap long lines. Looking into d/control all lines are wrapped at the first whitespace after 60 characters. Currently the longest line is currently 70 characters (see d/control posted above). This is significantly beyond typical terminal width and even ~5 characters below the average line length of e.g. util-linux control file in Debian Stretch. What are the Debian rules for line length? Below 50? > - d/rules could use some more whitespace. Where? The file is just 37 lines and in my opinion not hard to read. Any whitespace I could think of would just decrease readability by stretching the content. Each paragraph, containing at most 3 commands, is separated from the next by a blank line. Should there be a blank line between each single command? > - The py2 dependency is bad (very bad, especially at this point). > + There are only two years left until py2 EoL. Where did you find that? All "grep -i -r python2" hits are in files not to be included (see Py2/3 patch comments from above) or are centered around py2/py3 migration itself. Maybe I missed something. > - d/links suggests binaries are not being installed into standard locations. Because Python when invoked via she-bang adds by default the binaries' directory to the search path. I do not want to have all other binaries of a target system (some might be Python code by themself) on the search path for security reasons. As backups are usually run as root, a single unrelated package could thus allow to gain privileges. > - d/NEWS is not needed here and will be needlessly noisy for users. Removed. > - d/install should use wildcards to grab docs, instead of a file list This was done with forward compatibility in mind - future documentation without relevance for the package should not be included automatically to keep the package small and to avoid having useless documentation included (whitelisting vs. blacklisting).
Bug#849754: Update from IRC discussion
In response to discussion, packaging was adjusted: * Added lintian override to ignore non-standard directory perms explaining the read restrictions * Ignore possible-unindented-list-in-extended-description (false positive) * Added docstrings to systemd service files, reported when using lintian -EviIL +pedantic
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello Mentors, While the package in question (see [0]) is working 24/7 on multiple machines without problems, having created and transfered about 10k of data elements so far, also surviving updates, reboots, both the inclusion process but also the purging of obsolete RFS seems stuck. Should another round for inclusion be attempted or should the 2 bugs and mentors-site entry be closed/removed? Kind regards, hd PS: Current state: you might find [1] useful, especially message #16 (Sun, 1 Jan 2017) with a good (and demanding) review from Andreas Henriksson and the list of changes in response in message #23 (Thu, 04 May 2017). [0] https://mentors.debian.net/package/guerillabackup [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849754
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello Andreas, Andreas Henriksson writes: > ... > Sorry I have not had time to follow up to you. I simply don't have > time. Hopefully my previous comments has been of some use to you, > but I don't think I can help out anymore. In my opinion, your length review really helped me a lot to improve the quality of the package, especially it motivated me to review the Python2/Python3-requirements of the target machines and migrate to Python3 earlier than I would have done otherwise, even though it required lengthy burn-in tests afterwards. I regret, that I could not improve the situation about systemd: there were no responses from systemd list and I did not find ways to do better than now. The current configuration worked in all tests, survived all boots and updates but is not as clean as it should be. As from my point of view, that lightweight tool might also be useful for other Debian users, I hope, that someone else has the time to continue the review. The whole review state was captured in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849754 and should be good groundwork for the next review. Best regards, hd > On Thu, Aug 31, 2017 at 05:00:00AM +, halfdog wrote: > > Hello Andreas, > > > > I did not hear from you after the last mails, see messages from > > 04 May 2017 21:59, 23 Jun 2017 05:59. Are you still interested > > in doing the (quite tricky) review? > > > > I have now also tested the build procedures and the software on > > Debian Stretch, see today's upload of package to mentors.debian.org. > > > > Best regards, > > hd > > > > > > Regards, > Andreas Henriksson
Bug#849754: RFS: guerillabackup/0.0.0-1
Hello Andreas, I did not hear from you after the last mails, see messages from 04 May 2017 21:59, 23 Jun 2017 05:59. Are you still interested in doing the (quite tricky) review? I have now also tested the build procedures and the software on Debian Stretch, see today's upload of package to mentors.debian.org. Best regards, hd
Bug#858098: Also xrdp install fails on hosts with IPv6 disabled
Package will also fail to install on IPv6 disabled: Aug 05 17:14:40 localhost xrdp-sesman[16878]: (16878)(-1222109440)[DEBUG] libscp initialized Aug 05 17:14:40 localhost xrdp-sesman[16879]: (16879)(-1222109440)[INFO ] starting xrdp-sesman with pid 16879 Aug 05 17:14:40 localhost xrdp-sesman[16879]: (16879)(-1222109440)[ERROR] bind error on port '3350': 22 (Invalid argument) Aug 05 17:14:40 localhost xrdp-sesman[16879]: (16879)(-1222109440)[DEBUG] Closed socket 7 (AF_INET6 :: port 0) Even after temporary setting /proc/sys/net/ipv6/conf/all/disable_ipv6 to 0 repair will fail: Processing triggers for libc-bin (2.24-12) ... W: APT had planned for dpkg to do more than it reported back (0 vs 4). Affected packages: xrdp:i386 The package has to be purged and reinstalled before setting old /proc/sys/net/ipv6/conf/all/disable_ipv6 value.
Bug#849754: RFS: guerillabackup/0.0.0-1
Hi Andreas, It took me quite a while to address all your remarks... Andreas Henriksson wrote: > Hello halfdog, > > Thanks for your interest in debian packaging > > On Fri, Dec 30, 2016 at 03:16:55PM +, halfdog wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "guerillabackup" > [...] > > dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guer > illabackup_0.0.0-1.dsc > [...] > > > > As also stated in comment to https://mentors.debian.net/package/guerillabac > kup > > to avoid reviewers wasting time searching for dirty little package > > secrets, here are some pointers to things, I had problems with, > > when creating the package. Reviewers might disagree with my proposed > > solution, any feedback is very welcome! > > > > * Upstream Debian file templates: to support building of native > > packages using only the upstream source, Debian package files > > and build instructions are included already in upstream. To > > avoid duplication of them when not (yet) needed, they are copied > > within "rules" in target "override_dh_auto_configure" > > Not a fan here. :P > From a Debian(-only) perspective this complicates things for no > real gain. If you package things in Debian it's probably very > unlikely people will get their packages from elsewhere, specially > if they need to both build it themselves and follow a procedure > for doing so that's completely alien.. (but what do I know > about the actual problem you're trying to solve.) I only hoped to perform some dedup, but ... > I'm hoping DEP14 can instead be a replacement solution > for handling this (and also other reasons). ... if I understand http://dep.debian.net/deps/dep14/ correctly, building for different vendors in future should follow another scheme anyway, where deduplication is not an option. So I removed that stuff and duplicated all relevant upstream debian/* files to the non-native Debian quilt files also. > > * (Re)starting units on upgrade: As stated in documentation, two > > services can be used also from commandline (on demand) or as > > non-root user, depending on end user use cases. Thus it is intended, > > that the two systemd units are not enabled by default. Also > > a user may start them manually without enabling them. With upgrade > > following problem may arise: with standard debhelper means it > > was not possible to > > 1) stop all running units and > > 2) after update start only those, that were running beforehand. > > Solution: > > 1) do not use debhelper for stopping/starting of units, > > 2) find out in "prerm" which units are currently running, stop them and > > 3) in "postinst" start only those, that were running in step 1) > > Pretty please do not try to reinvent systemd integration on your own. > This is just way to easy to get wrong. If the current helpers does > not work for you it's either likely because you're using them wrong > and/or because they should be improved. Anything else is likely just > causing extra work and pain. > > Please swing by either the irc channel or contact the mailing list > for the Debian systemd maintainers. They're very skilled and usually > happy to help (time permitting). They are likely also the people > you need to get to review your package anyway if you invent your > own maintainer script scheme. I tried to get response from the mailing list, see http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-March/014551.html Also got to the IRC channel "#debian-systemd" with same result. As there are no responses proposing better solutions and the conditional service restarting code works as expected, I would propose keeping the current solution until bugreports are received. If insufficient, I would try to contact them again. > > * Use of .pyc files: As I do not fully understand the consequences > > of using .pyc files, especially in conditions where backup might > > be more important, e.g. when disks start already failing and > > py/pyc files might fall out of sync, I decided not to use them > > until I understand the possible risks. As codebase is very small > > and program is long-running, overhead from JIT-compiling should > > be not an issue. > > Not an expert on python packaging myself, but I think Debian python > packaging helpers should generate postinst code to automatically > generate the .pyc files on install. I guess the reason you can't > ship them is because then you need to build them with th
Bug#849754: RFS: guerillabackup/0.0.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "guerillabackup" * Package name: guerillabackup Version : 0.0.0-1 Upstream Author : halfdog * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3 Section : misc It builds those binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.0-1.dsc More information about guerillabackup can be obtained from https://github.com/halfdog/guerillabackup Changes since the last upload: * Initial packaging of guerillabackup (Closes: #849714) As also stated in comment to https://mentors.debian.net/package/guerillabackup to avoid reviewers wasting time searching for dirty little package secrets, here are some pointers to things, I had problems with, when creating the package. Reviewers might disagree with my proposed solution, any feedback is very welcome! * Upstream Debian file templates: to support building of native packages using only the upstream source, Debian package files and build instructions are included already in upstream. To avoid duplication of them when not (yet) needed, they are copied within "rules" in target "override_dh_auto_configure" * (Re)starting units on upgrade: As stated in documentation, two services can be used also from commandline (on demand) or as non-root user, depending on end user use cases. Thus it is intended, that the two systemd units are not enabled by default. Also a user may start them manually without enabling them. With upgrade following problem may arise: with standard debhelper means it was not possible to 1) stop all running units and 2) after update start only those, that were running beforehand. Solution: 1) do not use debhelper for stopping/starting of units, 2) find out in "prerm" which units are currently running, stop them and 3) in "postinst" start only those, that were running in step 1) * Use of .pyc files: As I do not fully understand the consequences of using .pyc files, especially in conditions where backup might be more important, e.g. when disks start already failing and py/pyc files might fall out of sync, I decided not to use them until I understand the possible risks. As codebase is very small and program is long-running, overhead from JIT-compiling should be not an issue. Regards, hd
Bug#849714: guerillabackup -- resilient, distributed backup and archiving solution
Package: wnpp Severity: wishlist Package name: guerillabackup Version: 0.0.0 Upstream Author: halfdog <m...@halfdog.net> URL: https://github.com/halfdog/guerillabackup Sources URL: https://github.com/halfdog/guerillabackup.git License: LGPLv3 Programming Lang: Python Description: guerillabackup supports backup generation and transfer especially in non-standard environments like on private equipment. Dependencies: python Long description: The tool supports asynchronous, local-coordinated, distributed secure backup generation, forwarding, verification, storage and deletion even in rugged environments. The system is open to integration of own code. The codebase is very small and kept simple to ease auditing. . Unlike business backup solutions, guerillabackup also considers following conditions that might be encountered with private use: * infrastructure uptime below 99%, e.g. machines not always powered * poor network connectivity, e.g. mobile access, parallel video streaming * poor physical access and anti-theft protection of machines * no security monitoring of machines . See /usr/share/doc/guerillabackup/Design.txt section "Requirements" for more information. After receiving the wnpp bug issue number and adding it to debian/changelog, final package will be available at https://mentors.debian.net/package/guerillabackup
Bug#846843: Ulogd creates log directory, log files world readable by default
Package: ulogd2 Version: 2.0.4-2+deb8u1 Severity: serious Tags: security After a fresh install of ulogd2, logging directory has following permissions: # ls -al /var/log/ulog total 8 drwxr-xr-x 2 root root 4096 Dec 3 16:22 . drwxr-xr-x 10 root root 4096 Dec 3 16:22 .. -rw-r--r-- 1 root root0 Dec 3 16:22 syslogemu.log Depending on packets logged, users on machine may gain much more information than available via /proc/[pid] - which would be just the remote address of TCP connections. This is especially annoying when ulogd is used to create full packet captures of some connections as recommended in howtos. As ulogd is started with UID=0 and drops permissions, I would recommend changing default permissions for directory to 0700 and 0600 for files. For rare scenarios, where users would really need to let another software read that data, permissions should be changed on those machines only.
Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This issue was assigned CVE-2014-1438 and has now been fixed in kernel mainline. Since analysis showed, that it is not specific to vm86-mode, new bug description could be similar to OSVDB: restore_fpu_checking Function Unhandled FPU Exception Local DoS See [1] for patch, [2] for information about CVE-assignment, at [3] you can find references to various resources related to this bug, e.g. the mailing list posts, POC code for crash and privilege escalation. [1] https://lkml.org/lkml/2014/1/11/196 [2] http://www.openwall.com/lists/oss-security/2014/01/14/1 [3] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/ - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLU4GUACgkQxFmThv7tq+7CxgCdGHW5AIIGLoO0CXTuJypIYsvU xrYAnRFi2QvDrBs3tnIkxvF+F3xpGZAj =H8Vy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Hutchings wrote: On Fri, 2014-01-03 at 23:20 +, halfdog wrote: Here is some more information from my latest tests: * Although first observed with virtual-8086 mode, the bug is not specific to virtual-8086 mode, it can be triggered with normal x86 userspace code also, even with better reproducibility. * It seems, that when changing the FPU control word with fstcw just before exit of the process, then another process could suffer when doing __do_switch * By having two rogue processes writing data to each other via a socket, time and code-position of OOPS can be influenced. * When deactivating mmap_min_addr, the NULL-dereferences during task-switch are exploitable, if kernel memory layout is known from System.map, privilege escalation might be quite likely. This is why no-one sets mmap_min_addr to 0 any more... Yes, I know. It's just for learning purposes ... * I've not yet tried to build a 64-bit version, but since vm86-syscall is not required any more, there could be problems there also. You can find the new improved test code without virtual-8086 mode here: http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c I commented-out the mmap-ing as I just want to see the oops rather than work out how exploitable it might be. But I didn't get an oops when running on either the -486 or -686-pae kernel flavour, in a VM on an Intel or AMD 64-bit CPU, or directly on an Intel 64-bit CPU. (The AMD system is a server I don't want to take down.) Can you confirm that you are able to reproduce this without a VM, and send the contents of /proc/cpuinfo on the affected system(s)? So, after completing my privilege escalation-POC, I'm back on searching for the root cause. I've run tests without and within VirtualBox, the results were the same. The local-root also works on the native CPU without virtualization. So if you can't reproduce, the CPU or some CPU-related kernel features might be the problem: My CPU is a dual-core AMD, but the Debian 486-kernel does use only one of those: processor : 0 vendor_id : AuthenticAMD cpu family : 20 model : 1 model name : AMD E-350 Processor stepping: 0 microcode : 0x528 cpu MHz : 1596.563 cache size : 512 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc nonstop_tsc extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat hw_pstate npt lbrv svm_lock nrip_save pausefilter bogomips: 3193.12 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Another hot candidate might be the noxsave switch: [BUGS=X86] Disables x86 extended register state save and restore using xsave. The kernel will fallback to enabling legacy floating-point and sse state. While reading the Intel architecture manuals to develop the POC, I stumbled multiple times over relations between the problematic emms instruction, the FPU control word handling and the xsave instruction, but do not have a complete picture on that yet. - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLMkKoACgkQxFmThv7tq+5JBwCeNYfa/QmHq3sI2O45fDcwd62j Tb8An3iIs5yPFxIFBCIUGXX/PVrzB4xu =KZ07 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
Here is some more information from my latest tests: * Although first observed with virtual-8086 mode, the bug is not specific to virtual-8086 mode, it can be triggered with normal x86 userspace code also, even with better reproducibility. * It seems, that when changing the FPU control word with fstcw just before exit of the process, then another process could suffer when doing __do_switch * By having two rogue processes writing data to each other via a socket, time and code-position of OOPS can be influenced. * When deactivating mmap_min_addr, the NULL-dereferences during task-switch are exploitable, if kernel memory layout is known from System.map, privilege escalation might be quite likely. * I've not yet tried to build a 64-bit version, but since vm86-syscall is not required any more, there could be problems there also. You can find the new improved test code without virtual-8086 mode here: http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: linux-image-3.11-2-486 Version: 3.11.10-1 Tags: security When executing code in virtual-8086 mode via vm86 syscall, kernel seems to perform incomplete CPU state sanitation when switching tasks, thus causing OOPSes or complete machine lockup. See [1] for reproducers. Vrtual86SwitchToEmmsFault.c locks up reproducible when run in one VirtualBox guest, but fails to do so on real hardware. The random code tool Virtual86RandomCode.c might yield better results on those machines. [1] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/ [ 348.270712] fpu exception: [#1] [ 348.270763] Modules linked in: nfnetlink_log nfnetlink xt_multiport xt_hashlimit xt_tcpudp ipt_ULOG xt_LOG xt_conntrack iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables snd_pcm snd_page_alloc snd_timer snd parport_pc soundcore microcode psmouse serio_raw pcspkr evdev parport ac battery button i2c_piix4 i2c_core ext4 crc16 mbcache jbd2 sg sr_mod sd_mod cdrom crc_t10dif ata_generic ata_piix mptspi scsi_transport_spi mptscsih libata mptbase pcnet32 mii scsi_mod [ 348.270763] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.11-2-486 #1 Debian 3.11.10-1 [ 348.270763] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 348.270763] task: cf835400 ti: cf93 task.ti: cf84a000 [ 348.270763] EIP: 0060:[c10013e0] EFLAGS: 00010002 CPU: 0 [ 348.270763] EIP is at __switch_to+0x190/0x300 [ 348.270763] EAX: cd2eec00 EBX: cd2eec00 ECX: EDX: [ 348.270763] ESI: cf835400 EDI: 0001 EBP: cd2eedf8 ESP: cf931a40 [ 348.270763] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 348.270763] CR0: 80050033 CR2: b76997e0 CR3: 0d11a000 CR4: 0690 [ 348.270763] Stack: [ 348.270763] 4a6ef7ab ccee9c80 ccee9900 cf835400 c13978cf cd2eec00 00200082 c15de480 [ 348.270763] 0018 67bf6d70 cf93 cd2eec00 1625d3df 0051 cd2eec2c c1056e15 [ 348.270763] 00200086 000a cf931a90 c1006cc8 00393f1e 5d3e5d0f 0040 [ 348.270763] Call Trace: [ 348.270763] [c13978cf] ? __schedule+0x1ef/0x510 [ 348.270763] [c1056e15] ? update_curr+0x95/0x140 [ 348.270763] [c1006cc8] ? sched_clock+0x8/0x10 [ 348.270763] [c13973d5] ? schedule_hrtimeout_range_clock+0x165/0x180 [ 348.270763] [c1044e9f] ? __flush_work+0xbf/0x100 [ 348.270763] [d0a4fa59] ? nf_nat_get_offset+0x39/0x60 [nf_nat] [ 348.270763] [d0a68df7] ? tcp_packet+0x637/0xf40 [nf_conntrack] [ 348.270763] [c124932c] ? tty_write_room+0xc/0x20 [ 348.270763] [c1246fb9] ? n_tty_poll+0x189/0x1a0 [ 348.270763] [c13973ff] ? schedule_hrtimeout_range+0xf/0x20 [ 348.270763] [c11093a0] ? poll_schedule_timeout+0x20/0x40 [ 348.270763] [c1109c77] ? do_select+0x537/0x5f0 [ 348.270763] [c11094d0] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [c11094d0] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [c11094d0] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [c11094d0] ? poll_select_copy_remaining+0x110/0x110 [ 348.270763] [c12f688d] ? nf_iterate+0x7d/0x90 [ 348.270763] [c1067e6c] ? __getnstimeofday+0x2c/0x110 [ 348.270763] [c133f7f2] ? bictcp_cong_avoid+0x12/0x4a0 [ 348.270763] [c1067f55] ? getnstimeofday+0x5/0x20 [ 348.270763] [c131116b] ? tcp_ack+0x82b/0xdc0 [ 348.270763] [c10353a0] ? local_bh_enable+0x70/0x80 [ 348.270763] [c1300301] ? ip_finish_output+0x151/0x350 [ 348.270763] [c10c612a] ? put_compound_page+0xa/0xe0 [ 348.270763] [c1311b07] ? tcp_rcv_established+0xf7/0x7a0 [ 348.270763] [c12c1edc] ? sk_reset_timer+0xc/0x20 [ 348.270763] [c131a94e] ? tcp_v4_do_rcv+0x15e/0x3b0 [ 348.270763] [c12c3558] ? release_sock+0x88/0xf0 [ 348.270763] [c13088d7] ? tcp_sendmsg+0x177/0xc60 [ 348.270763] [c1056e15] ? update_curr+0x95/0x140 [ 348.270763] [c1109e5c] ? core_sys_select+0x12c/0x220 [ 348.270763] [c12beee1] ? sock_aio_write+0xe1/0x110 [ 348.270763] [c10f9cda] ? do_sync_write+0x6a/0xa0 [ 348.270763] [c112b673] ? fsnotify+0x203/0x2f0 [ 348.270763] [c1109fdf] ? SyS_select+0x8f/0xc0 [ 348.270763] [c100aca2] ? syscall_trace_leave+0xa2/0xb0 [ 348.270763] [c1398fef] ? syscall_call+0x7/0xb [ 348.270763] Code: e9 1d ff ff ff 8d b6 00 00 00 00 b8 7d 00 00 00 e8 36 b8 00 00 84 c0 0f 85 e1 fe ff ff 0f 06 8d 74 26 00 e9 d6 fe ff ff 8d 76 00 0f 77 db 83 4c 02 00 00 89 f6 8d b6 00 00 00 00 eb 66 b8 ff ff [ 348.270763] EIP: [c10013e0] __switch_to+0x190/0x300 SS:ESP 0068:cf931a40 [ 348.270763] ---[ end trace c3836805b501f815 ]--- [ 348.274764] [ cut here ] [ 348.278424] kernel BUG at /build/linux-tAcKXn/linux-3.11.10/kernel/exit.c:870! [ 348.278764] invalid opcode: [#2] [ 348.278764] Modules linked in: nfnetlink_log nfnetlink xt_multiport xt_hashlimit xt_tcpudp ipt_ULOG xt_LOG xt_conntrack iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
Bastian Blank wrote: Control: tag -1 moreinfo On Sun, Dec 29, 2013 at 09:12:35PM +, halfdog wrote: When executing code in virtual-8086 mode via vm86 syscall, kernel seems to perform incomplete CPU state sanitation when switching tasks, thus causing OOPSes or complete machine lockup. You only showed exceptions while running within VirtualBox. Please also show some while running on real hardware. Because I did not care to copy the OOPSes from the initrd via USB to crypto-disks since most of them were triggered in already well-known fault location, also primary problem at emms instruction (math_state_restore+0x3e/0x140 is a much easier target to hit). I'll try to capture on real hardware when hardware is idle again. [ 4194.121492] fpu exception: [#1] [ 4194.123114] Modules linked in: nfnetlink_log nfnetlink xt_multiport xt_hashlimit xt_tcpudp ipt_ULOG xt_LOG xt_conntrack iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables snd_pcm snd_page_alloc snd_timer snd parport_pc soundcore microcode psmouse serio_raw pcspkr evdev parport ac battery button i2c_piix4 i2c_core ext4 crc16 mbcache jbd2 sg sr_mod sd_mod cdrom crc_t10dif ata_generic ata_piix mptspi scsi_transport_spi mptscsih libata mptbase pcnet32 mii scsi_mod [ 4194.123114] CPU: 0 PID: 2326 Comm: Virtual86Random Not tainted 3.11-2-486 #1 Debian 3.11.10-1 [ 4194.123114] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 4194.123114] task: cf439400 ti: ccfd6000 task.ti: ccfd6000 [ 4194.123114] EIP: 0060:[c100230e] EFLAGS: 00010002 CPU: 0 [ 4194.123114] EIP is at math_state_restore+0x3e/0x140 [ 4194.123114] EAX: 8005003b EBX: cf439400 ECX: 007b EDX: [ 4194.123114] ESI: EDI: c1399bb0 EBP: 0400 ESP: ccfd7eb4 [ 4194.123114] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 4194.123114] CR0: 80050033 CR2: CR3: 0da55000 CR4: 0690 [ 4194.123114] Stack: [ 4194.123114] ccfd7ed0 c1399bb0 c1399c05 c1023f17 ccfd7ef8 c1399585 [ 4194.123114] be77 0400 [ 4194.123114] ee89 1000 00030202 03f8 1000 [ 4194.123114] Call Trace: [ 4194.123114] [c1399bb0] ? do_debug+0x160/0x160 [ 4194.123114] [c1399c05] ? do_device_not_available+0x55/0x70 [ 4194.123114] [c1023f17] ? SYSC_vm86+0x97/0x280 [ 4194.123114] [c1399585] ? error_code+0x65/0x70 [ 4194.123114] [c10243ed] ? SyS_vm86+0xd/0x10 [ 4194.123114] [c1398fef] ? syscall_call+0x7/0xb [ 4194.123114] Code: 00 89 d8 e8 15 62 00 00 85 c0 0f 85 95 00 00 00 fa 90 8d 74 26 00 e9 50 00 00 00 c7 83 4c 02 00 00 01 00 00 00 89 1d 74 cd 4d c1 0f 77 db 83 4c 02 00 00 89 f6 eb 3e b8 ff ff ff ff 8b bb 50 02 [ 4194.123114] EIP: [c100230e] math_state_restore+0x3e/0x140 SS:ESP 0068:ccfd7eb4 See [1] for reproducers. Vrtual86SwitchToEmmsFault.c locks up reproducible when run in one VirtualBox guest, but fails to do so on real hardware. The random code tool Virtual86RandomCode.c might yield better results on those machines. So it does _not_ fail on real hardware. Why do you think this is a kernel bug then? The specific test does not kill the idle task on real hardware but faults in a different way (math_state_restore). Perhaps memory layout is somehow relevant. Did you try the random code test? Perhaps the fault is specific to AMD-processors? You can use 'Virtual86RandomCode /dev/urandom /dev/null', on this hardware it took just some ms to trigger first faults. -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658264: xpdf totally unusable due to memory corruption in globalParams class (namespace conflict with libpoppler)
Just out of interest: Is this really a namespace conflict? As I understand the code, xpdf and libpoppler should want to use an object of same class from the same namespace, but due to some reason, the class code was duplicated to xpdf. I'm not c++ expert, but perhaps this was to make linking of xpdf simpler. I did a short analysis before reading this bug report by myself ( http://www.halfdog.net/Security/2012/XpdfCrashAnalysisUbuntuPrecise/ ). So from my opinion, with the patch attached, this will fix the problem only for some combination of xpdf/poppler versions and will make problem reappear in future. Could someone confirm that? -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591032: Anomaly in ./usr/share/kernel-package/pkg/image/postinst of kernel-package 12.036
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: kernel-package Version: 12.036 When installing home-built kernel packages, I observed error similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561287 Searching for the cause, I found an anomaly in ./usr/share/kernel-package/pkg/image/postinst which might be a bug: All var defs in ./usr/share/kernel-package/pkg/image/postinst line 28-55 occur again in substitution patterns line 82-106 to read values from some conffile, except for kimage, the varname has an additional m in front. line 105 $mkimage = $1 if m/^\s*mkimage\s*=\s*(.+)$/i; Changing the line does not fix the problem for me, but perhaps I have screwed up something else on my system. - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxT28QACgkQxFmThv7tq+6CGgCfWHBpo+wI+t8XQTVBGt5BIbNn 1n8AoI3w5ezaUTYjzISRYHYkAw/ev81y =3GQb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
