binary:libprocyon-java is NEW.
binary:procyon-decompiler is NEW.
source:procyon is NEW.
Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be
On Sat, 15 Oct 2016, Emmanuel Bourg wrote:
> Hum old bug, it should have been closed since we use the 0.x version for
> this library now.
Well closure-compiler doesn’t, it depends on the debian version,
and so do all things that depend on it.
> Le 15/10/2016 à 00:29, Thorsten Glaser a écrit :
>
Hum old bug, it should have been closed since we use the 0.x version for
this library now.
Le 15/10/2016 à 00:29, Thorsten Glaser a écrit :
> Ideally, yes. I need one in com/google/code/findbugs/jsr305 at the
> very least, to package minify-maven-plugin which depends on Google’s
>
Package: yui-compressor
Version: 2.4.7-2
Severity: normal
yui-compressor is unknown to /usr/share/maven-repo and the
maven-debian-helper stuff, leading to failures such as…
Resolving com.yahoo.platform.yui:yuicompressor:jar:2.4.7 of scope runtime...
[check dependency with bundle type]
In
procyon_0.5.32-1_amd64.changes uploaded successfully to localhost
along with the files:
procyon_0.5.32-1.dsc
procyon_0.5.32.orig.tar.xz
procyon_0.5.32-1.debian.tar.xz
libprocyon-java_0.5.32-1_all.deb
procyon-decompiler_0.5.32-1_all.deb
Greetings,
Your Debian queue daemon
On Thu, 18 Oct 2012, tony mancill wrote:
> same location it was found in for -4. Should there be a debian version
> under both org/jsr-305/jsr-305 and com/google/code/findbugs/jsr305 ?
Ideally, yes. I need one in com/google/code/findbugs/jsr305 at the
very least, to package minify-maven-plugin
Package: maven-debian-helper
Version: 2.1.1
Severity: minor
$ dpkg -S /usr/bin/licensecheck
licensecheck: /usr/bin/licensecheck
Maybe it once was, but currently it sure isn’t.
This can be confusing.
-- System Information:
Debian Release: stretch/sid
APT prefers unreleased
APT policy: (500,
Processing control commands:
> severity -1 normal
Bug #840685 [tomcat8] TOCTOU race condition in initscript on chown'ing JVM_TMP
temporary directory
Severity set to 'normal' from 'critical'
> found -1 8.0.14-1
Bug #840685 [tomcat8] TOCTOU race condition in initscript on chown'ing JVM_TMP
Control: severity -1 normal
Control: found -1 8.0.14-1
Hi Paul,
On Sat, Oct 15, 2016 at 07:25:59AM +1100, paul.sz...@sydney.edu.au wrote:
> Dear Salvatore,
>
> > You are operating here outside of /tmp (sticky world-writable
> > directory) which the above issue for the init scripts relies on,
>
Dear Salvatore,
> You are operating here outside of /tmp (sticky world-writable
> directory) which the above issue for the init scripts relies on,
> right? fs.protected_(hardlinks|symlinks) is exactly a hardening for
> those issues:
> https://www.kernel.org/doc/Documentation/sysctl/fs.txt
I
Dear Markus,
Sorry to reply again.
> ... But there is another rm -rf "$JVM_TMP" command in the stop target
> that would remove your symlink again.
I now see what you mean. There is an rm when you "stop" tomcat, and
another in the "start"; so maybe there are two in restart. No matter:
I watch
Hi Paul,
Markus followed already up, I just want to give some additional
comments on the below:
On Fri, Oct 14, 2016 at 07:07:52PM +1100, paul.sz...@sydney.edu.au wrote:
> Dear Salvatore,
>
> > ... if the attacher created a symlink between the rm and the mkdir
> > then mkdir will still fail
Dear Markus,
> First of all you can only gain write permissions as the tomcat8 user if
> you exploit an yet unknown security vulnerability in a web application
> or Tomcat itself. Debian's tomcat8 user has no shell access by default.
Yes, this is a privilege escalation issue: exactly as in
Processing commands for cont...@bugs.debian.org:
> retitle 840685 TOCTOU race condition in initscript on chown'ing JVM_TMP
> temporary directory
Bug #840685 [tomcat8] tomcat8: DSA-3670 incomplete
Changed Bug title to 'TOCTOU race condition in initscript on chown'ing JVM_TMP
temporary directory'
FYI: The status of the libapache-mod-jk source package
in Debian's testing distribution has changed.
Previous version: 1:1.2.41-1
Current version: 1:1.2.42-1
--
This email is automatically generated once a day. As the installation of
new packages into testing happens multiple times a day
On 14.10.2016 10:07, paul.sz...@sydney.edu.au wrote:
[...]
>> So while I think it should be fixed, this would not warrant a DSA,
>> since mitigated by default in Debian.
>
> No mitigation: fix and DSA, please!
I agree with Salvatore. I have tested the following:
First of all you can only gain
binary:sweethome3d-furniture-nonfree is NEW.
Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.
Packages are routinely processed
sweethome3d-furniture-nonfree_1.6.2-2_amd64.changes uploaded successfully to
localhost
along with the files:
sweethome3d-furniture-nonfree_1.6.2-2.dsc
sweethome3d-furniture-nonfree_1.6.2-2.debian.tar.xz
sweethome3d-furniture-nonfree_1.6.2-2_all.deb
Greetings,
Your Debian queue
sweethome3d-furniture-nonfree_1.6.2-2_amd64.changes uploaded successfully to
ftp-master.debian.org
along with the files:
sweethome3d-furniture-nonfree_1.6.2-2.dsc
sweethome3d-furniture-nonfree_1.6.2-2.debian.tar.xz
sweethome3d-furniture-nonfree_1.6.2-2_all.deb
Greetings,
Your
Dear Salvatore,
> ... if the attacher created a symlink between the rm and the mkdir
> then mkdir will still fail with -p on a symlink. (Or do I miss
> something?). ...
Yes, you missed a simple test:
$ mkdir mydir
$ ln -s mydir mylink
$ ls -ld my*
drwx-- 2 psz amstaff 4096 Oct 14 18:46
Hi Paul, hi Markus,
On Fri, Oct 14, 2016 at 08:42:11AM +1100, paul.sz...@sydney.edu.au wrote:
> Dear Markus,
>
> >> [ I contacted t...@security.debian.org about this, but no response ... ]
> > ... Please send them to the security team
> > first and not to a public mailing list.
>
> I did. They
21 matches
Mail list logo