Bug#834747: nginx-extras: Feature request: Add 3rd party module graphite-nginx-module.

[Thomas Ward (Dark-Net)]

Please note that there is currently a "Won't Fix" for "No New Modules
or Flavors", which may still apply here.  This is bug #790623
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790623)

--
Thomas

On Thu, Aug 18, 2016 at 10:39 AM, Roman V. Nikolaev  wrote:
> Package: nginx-extras
> Version: 1.10.1-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Please add new module to nginx-extras:
> graphite-nginx-module - an nginx module for collecting location stats into 
> Graphite.
>
> Url: https://github.com/mailru/graphite-nginx-module
> License: BSD
> Depends: lua-nginx-module
>
> -- System Information:
> Debian Release: 8.4
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
> 'testing-proposed-updates'), (500, 'stable-updates'), (500, 
> 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages nginx-extras depends on:
> ii  libc6   2.23-2
> ii  libexpat1   2.1.0-6+deb8u2
> ii  libgd3  2.2.1-1
> ii  libgeoip1   1.6.2-4
> ii  liblua5.1-0 5.1.5-7.1
> ii  libpam0g1.1.8-3.1+deb8u1+b1
> ii  libpcre32:8.35-3.3+deb8u4
> pn  libperl5.18 
> ii  libssl1.0.0 1.0.1k-3+deb8u5
> ii  libxml2 2.9.3+dfsg1-1
> ii  libxslt1.1  1.1.28-2+b2
> ii  nginx-common1.6.2-5+deb8u2
> ii  perl5.20.2-3+deb8u5
> pn  perlapi-5.18.1  
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> nginx-extras recommends no packages.
>
> Versions of packages nginx-extras suggests:
> pn  nginx-doc  
>

Bug#766957:

[Thomas Ward (Dark-Net)]

I can maybe take a stab at backporting to 0.206, as it's on my radar
to do anyways.

Note this though: I don't think we should outright disable SSLv3 in a
stable release.  There is a code commit in the pull requests queue
waiting for inclusion that allows the specification of SSLv3 being
disabled - this in turn would allow 0.206 users to disable SSLv3 if
they wish and not change a default that would maybe cause undesired
confusion and results.  Downstream in Ubuntu, the Security Team will
not include the SSLv3-disabled-always changes, but may consider the
pending Configure disabling of protocols commits.

--
Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767456: disable SSLv3 by default

[Thomas Ward (Dark-Net)]

Okay, so after poking #debian-security on OFTC, Thijs said the
following:  (Or at least I believe it's Thijs):

[2014/11/01 11:25:15] thijs_ teward: I think the ideal package does
not have SSLv3 included in its default settings. With Apache in Debian
is quite the case because /etc/apache2/conf-available/ssl.conf will
disable SSLv3 so any vhost using SSL without explicitly overriding the
SSLProtocols will not have it
[2014/11/01 11:26:28] thijs_ that nginx disables it in a
configuration example is good, but I would think it's much better if
someone creates a vhost without explicit protocol specification, it
would not do SSLv3

To that end, I went fussing around with the code of the SSL module.
Attached is a patch which should do the trick, and disable SSLv3
support if ssl_protocols is NOT defined.

Before this patch is included, though, we should really consider
whether we actually *want* to disable SSLv3 by default and potentially
break nginx configurations which need SSLv3 and don't have
ssl_protocols defined.  At the very least, a NEWS entry needs to be
added for this.  If this change is accepted, I'll make a blog post
about it, but only if it's included.

--
Thomas


disable_sslv3_default_protocol.patch
Description: Binary data

Bug#767456: disable SSLv3 by default

[Thomas Ward (Dark-Net)]

fixed 1.6.2-3
thanks

Confirmed: This was done already.  The commit this was done in was
this one: 
http://anonscm.debian.org/cgit/collab-maint/nginx.git/commit/?id=9a4e0f0a698bee2b03b7f417ad9286e5eb22141e

1.6.2-3, which had this fix already, was uploaded and accepted to
Unstable on 2014-10-16, according to the package tracker
(https://packages.qa.debian.org/n/nginx.html)  This is confirmed in
the 1.6.2-4 changelog in Unstable
(http://metadata.ftp-master.debian.org/changelogs/main/n/nginx/unstable_changelog).

Dissection of the package 1.6.2-4 also shows that the default SSL
stanza has an ssl_protocols line of `ssl_protocols TLSv1 TLSv1.1
TLSv1.2`.  Coupled with the OpenSSL updates made by the Debian
security team to support TLS_FALLBACK_SCSV to prevent the protocol
downgrade attack from TLSv1 to SSLv3, POODLE is effectively mitigated
with the now-default config stanzas for SSL.  (This assumes also that
a user is using the default SSL config sections.  A large portion of
(albeit newer) users do use the default config stanzas, or at least
use it as a base, and it can be argued that competent administrators
will already disable the vulnerable protocols in their own site
configs separately.)

--
Thomas Ward

On Fri, Oct 31, 2014 at 7:28 AM, Thomas Ward tew...@dark-net.net wrote:
 I thought this was already done?  I checked the packaging myself and this 
 change was already in there, or at least in git.  (the default ssl stanza in 
 the config has SSLv3 dropped from the ciphers list in the git tree for the 
 Debian package already, I checked the commit logs myself)


 --
 Thomas


 On Oct 31, 2014, at 03:37, Thijs Kinkhorst th...@debian.org wrote:

 Package: nginx
 Version: 1.6.2-2
 Severity: important

 Hi,

 Please disable the legacy SSLv3 protocol by default for installations of
 nginx. It doesn't need to be disabled completely per se, but should not
 be available on a default installation.

 This helps to defend against the recent POODLE attack (CVE-2014-3566).

 Thanks,
 Thijs



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762494: Please update the Lua module to upstream git master

[Thomas Ward (Dark-Net)]

Apparently upstream has posted a new tagged version of the Lua module,
v0.9.13rc1.

Can we update the package to include this tagged revision, to address this bug?

(Also note: bug retitled)


--
Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764527: Package Tracker URL Problem Resolution and Request to Look Into Updating the Package

[Thomas Ward (Dark-Net)]

Source: libpff
Severity: wishlist

Hello.

Firstly, it should be made known that packages.qa.debian.org is
showing that there is a problem with the URLs for this package.
According to what I could find, the libpff project moved away from
sourceforge.  It looks like it was located on Google Code for a while,
but has since moved to GitHub at https://github.com/libyal/libpff
(this assumption is based on the owner of the libyal group on GitHub
being the same person who filed the ticket at SourceForge requesting
project removal - http://sourceforge.net/p/forge/site-support/3913/
and is also based on Google searches for the libpff project.)

Secondly, the version currently provided by Debian appears to be
several years old.  Downstream in Ubuntu and elsewhere, it looks like
users are trying to use these tools but are forced to compile the
software to get the newer software.  While this is typically not an
issue for power users, for the less technically inclined with the
coding and compile-from-scratch side of OSS it is a disadvantage.  To
that end, it may be prudent to investigate whether the software can be
updated in Debian.


--
Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762494: Please update the Lua module to upstream git master

[Thomas Ward (Dark-Net)]

Source: nginx
Severity: wishlist

Hello.

I would like to request that the Lua module be updated to the version in
its latest git master branch.  I am requesting this early, ahead of future
upstream versions of nginx uploaded to Debian.

This request is based on the Mainline branch, which I package in the
downstream Ubuntu PPAs, and directly base its debian/ folder off of Debian
Unstable.  The latest mainline branch, 1.7.5 changes the API and causes the
Lua module to fail to build in its current form.  While this API change
does not change here, there is added into the module an `if` block which
determines which code to use based on the version of NGINX it's being built
with.

As this is related to a future hypothetical fail to build error, I would
like the module to be updated to include the fix ahead of future API
changes in the nginx versions.


--
Thomas