Re: Should icedove be renamed in oldstable?
On Tue, 28 Feb 2017 23:15:24 +0100 Guido Günther wrote: > On Tue, Feb 28, 2017 at 09:17:38PM +0100, Ola Lundqvist wrote: > > Hi LTS Team, Guido and Christoph > > > > In the dla-needed.txt file I found the following lines: > > > > "icedove > > NOTE: maintainer currenlty planx to rename to thunderbird with the next > > NOTE: upstream version (#851989). Jessie / Wheezy should do the same." > > > > I must admit that I do not really see the point in changing the name in > > neither stable nor oldstable. > > Since we're following upstream versions anyway not doing so will > significantly increase the backporting and testing efforts. Isn't it the same as if the exact upstream package is not available any more? It is a question of money/working hours if the support can be done. Can someone calculate how many hours per month or version update are needed if artwork is changed to icedove. I don't know about the usual way to do it, maybe my ideas are plain old. How about: icedove will be EOL with a message in check-support-status about the change. 1. people installing icedove will be encouraged to install thunderbird or the meta package (see 3.) 2. people having icedove installed can (have to if 3. is not available) run a script to migrate data, directory names etc. to thunderbird 3. people who want the old icedove can choose a meta package, that installs thunderbird and a package with symbolic links. The user gets thunderbird with the art work of thunderbird but with file and directories sym links so private scripts etc. can still be used. (symbolic links for the binaries, the config files in home directories and every changed file in the package file list and a symbolic link the /etc/skel for users added later) 4. backporting thunderbird to icedove with icedove artwork can be done if somebody pays for. Greets Jens Korte Korte
Re: Should icedove be renamed in oldstable?
Hi Guido Now I understand the point. No objections then. // Ola On 28 February 2017 at 23:15, Guido Günther wrote: > On Tue, Feb 28, 2017 at 09:17:38PM +0100, Ola Lundqvist wrote: > > Hi LTS Team, Guido and Christoph > > > > In the dla-needed.txt file I found the following lines: > > > > "icedove > > NOTE: maintainer currenlty planx to rename to thunderbird with the next > > NOTE: upstream version (#851989). Jessie / Wheezy should do the same." > > > > I must admit that I do not really see the point in changing the name in > > neither stable nor oldstable. > > Since we're following upstream versions anyway not doing so will > significantly increase the backporting and testing efforts. So far > backporting Icedove was mostly a no brainer and we have benefitted 100% > percent from the work done by Carsten and Christoph in unstable / > testing. Much of this work is related to keeping the Icedove/Iceowl > branding in shape for the package and it's translations (look in the > patch-queue). > > Furthermore we're finally in sync with Firefox again which did the > renaming in a stable release too. > > I had a look at Carsten's work regarding the profile migration and I see > no reason why we should not do it in wheezy (iff Christoph intends to do > it for Jessie, which I assume). > > Cheers, > -- Guido > -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
LTS Report for February 2017
For February I spent 5.5 hours as follows: - php5: CVE-2016-10159, CVE-2016-10160, CVE-2016-10161, PHP bug 71323, PHP bug 70979, PHP bug 71039, PHP bug 71459, PHP bug 71391, and PHP bug 71335: integrated/backported upstream fixes, verified fixes, and ensured unit tests passed - php5: built and tested final package, uploaded, and released advisory - libevent: Took initial steps on this package until Bálint Réczey spoke up to say that he was becoming co-maintainer and wanted to perform the LTS update Regards, -Roberto -- Roberto C. Sánchez
LTS report February 2017
For February, I spent about 3 hours as follows: * review and upload apache2 DLA-841-1 fixing the nasty and obscure CVE-2016-8743, thanks everyone for the reviews and testing! * examine and postpone the kgb-bot DOS issue * backport the CVE-2016-7478 patch for php5 I'll catchup with my hours in march. A. -- Music gives a soul to the universe, wings to the mind, flight to the imagination and life to everything - Plato
Re: [SECURITY] [DSA 3792-1] libreoffice security update
Hi, On Tue, Feb 28, 2017 at 01:51:08AM +0100, Bálint Réczey wrote: > Do you have a PoC for testing? > I tried triggering the issue on Wheezy without any luck so far. Forwarded you the original mail from September in private mail. Regards, Rene
Re: [SECURITY] [DSA 3792-1] libreoffice security update
Hi, 2017-03-01 21:48 GMT+01:00 Rene Engelhard : > Hi, > > On Tue, Feb 28, 2017 at 01:51:08AM +0100, Bálint Réczey wrote: >> Do you have a PoC for testing? >> I tried triggering the issue on Wheezy without any luck so far. > > Forwarded you the original mail from September in private mail. Thanks! I'm testing it. Cheers, Balint
Re: Guessing package version for DLA template
Hi,
Thanks for all the input!
2017-02-28 9:12 GMT+01:00 Sébastien Delafond :
> On Feb/28, Peter Palfrader wrote:
>> Maybe we should be able to pass the name of the .changes file to
>> gen-DSA, and then the script can go and use all the information from
>> there?
>
> Implementation-wise, this sounds like a much more sensible approach, but
> since the *.changes files may not live on the machine where the advisory
> is drafted, I'd still lean toward making this behavior optional.
The originally proposed patch did not cover all use-cases indeed.
I agree that improving the documentation will help a bit, but I think
it will not help much and it will not make preparing DSA-s/DLA-s
much easier.
I have prepared a patch to optionally prepare the template using:
bin/gen-DSA package.changes
Cheers,
Balint
From 2e58b6fddab440f99602fa82c5119fe74aa7a13d Mon Sep 17 00:00:00 2001
From: Balint Reczey
Date: Thu, 2 Mar 2017 01:56:47 +0100
Subject: [PATCH] gen-DSA, gen-DLA: Read details from .changes
Package name, version, bug(s) and cve(s) are filled from .changes
file.
---
bin/gen-DSA | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/bin/gen-DSA b/bin/gen-DSA
index 80d3251..5b033a5 100755
--- a/bin/gen-DSA
+++ b/bin/gen-DSA
@@ -43,10 +43,14 @@ export LC_ALL=C
}
[ $# -ge 1 ] || {
-echo "usage: $0 [--save] [--embargoed|--unembargo] [$IDMODE] package [regression] [cve(s) [bugnumber(s)]]"
+echo "usage: $0 [--save] [--embargoed|--unembargo] [$IDMODE] package[.changes] [regression] [cve(s) [bugnumber(s)]] "
echo " '$IDMODE' is the $IDMODE number, required when issuing a revision"
echo " 'cve(s)' and 'bugnumber(s)' can be passed in any order but"
echo " always AFTER the description"
+echo ""
+echo " When specifying package.changes the package name, version, additional bug(s) and cve(s)"
+echo " are parsed from the .changes file."
+echo ""
echo " If it doesn't like your bug number, prefix it with # and report"
exit 1
} >&2
@@ -153,7 +157,16 @@ if printf '%s' "$1" | grep -Eq '^('"$IDMODE"'-|)[0-9]+(-[0-9]+|)$'; then
shift
fi
-PACKAGE="$(tolower "$1")"
+PACKAGE=
+CHANGES=
+
+if echo "$1" | grep -q '_.*\.changes$'; then
+CHANGES="$1"
+PACKAGE=$(awk '/^Source: / {print $2}' $CHANGES)
+else
+PACKAGE="$(tolower "$1")"
+fi
+
shift
TYPE=security
@@ -183,6 +196,21 @@ while [ $# -gt 0 ]; do
shift
done
+if ! [ -z "$CHANGES" ]; then
+# parse info from .changes file
+# Version can occur in GPG signature, thus we exit on first occurence
+version="$(awk '/^Version: / {print $2; exit 0}' $CHANGES)"
+dist="$(awk '/^Distribution: / {print $2}' $CHANGES | sed 's/-.*//')"
+export ${dist}_VERSION="$version"
+
+for bug in $(awk '/^Closes: / {sub(".*"$2,$2); print $0}' $CHANGES); do
+BUGNUM="$BUGNUM ${bug#\#}"
+done
+for cve in $(awk 'BEGIN {RS="[ ():\n]" } /^CVE-[0-9]+-[0-9]+$/ {print $1}' $CHANGES); do
+CVE="$CVE $cve"
+done
+fi
+
BUGNUM="$(split_n_sort "$BUGNUM")"
CVE="$(split_n_sort "$CVE" -V)"
--
2.1.4
mcollective cve-2016-2788
Details of this bug seem to be very scarce. I can't find any information
on how to reproduce, and I can't find git source. I can't even tell if
wheezy is vulnerable or not.
Furthermore this package is very old in all distributions including
unstable.
About the best I can find is this bug is present in 2.8.8 but fixed in
2.8.9. So I did a diff, and only included *.rb files (this filters out a
lot of changes to the documentation files).
My suspicion is that the changes to /lib/mcollective/matcher/scanner.rb might
be relevant.
The changes to /lib/mcollective/matcher.rb might also be significant.
diff -ruN mcollective-2.8.8/install.rb mcollective-2.8.9/install.rb
--- mcollective-2.8.8/install.rb2016-03-12 09:56:24.0 +1100
+++ mcollective-2.8.9/install.rb2016-07-21 03:53:53.0 +1000
@@ -110,7 +110,7 @@
#
def prepare_installation
InstallOptions.configs = true
-
+ InstallOptions.batch_files = true
# Only try to do docs if we're sure they have rdoc
if $haverdoc
InstallOptions.rdoc = true
@@ -149,6 +149,9 @@
opts.on('--plugindir[=OPTIONAL]', 'Installation directory for plugins',
'Default /usr/libexec/mcollective') do |plugindir|
InstallOptions.plugindir = plugindir
end
+opts.on('--no-batch-files', 'Prevents installation of batch files for
windows', 'Default off') do |batch_files|
+ InstallOptions.batch_files = false
+end
opts.on('--quick', 'Performs a quick installation. Only the',
'installation is done.') do |quick|
InstallOptions.rdoc= false
InstallOptions.ri = false
@@ -293,6 +296,7 @@
# Change directory into the mcollective root so we don't get the wrong files
for install.
cd File.dirname(__FILE__) do
+ prepare_installation
# Set these values to what you want installed.
configs = glob(%w{etc/*.dist})
erbs = glob(%w{etc/*.erb})
@@ -301,7 +305,8 @@
rdoc = glob(%w{bin/* lib/**/*.rb README* })
libs = glob(%w{lib/**/*})
plugins = glob(%w{plugins/**/*})
- if WINDOWS
+
+ if WINDOWS && InstallOptions.batch_files
if InstallOptions.service_files
windows_bins = glob(%w{ext/windows/*.bat ext/windows/*.rb})
else
@@ -310,14 +315,12 @@
end
check_prereqs
- prepare_installation
-
build_rdoc(rdoc) if InstallOptions.rdoc
do_configs(configs, InstallOptions.configdir, 'etc/|\.dist') if
InstallOptions.configs
do_configs(erbs, InstallOptions.configdir) if InstallOptions.configs
do_bins(bins, InstallOptions.bindir)
do_bins(sbins, InstallOptions.sbindir)
- do_bins(windows_bins, InstallOptions.bindir, 'ext/windows/') if WINDOWS
+ do_bins(windows_bins, InstallOptions.bindir, 'ext/windows/') if WINDOWS &&
InstallOptions.batch_files
do_libs(libs, InstallOptions.sitelibdir)
do_libs(plugins, InstallOptions.plugindir, 'plugins/')
end
diff -ruN mcollective-2.8.8/lib/mcollective/matcher/scanner.rb
mcollective-2.8.9/lib/mcollective/matcher/scanner.rb
--- mcollective-2.8.8/lib/mcollective/matcher/scanner.rb2016-03-12
09:56:24.0 +1100
+++ mcollective-2.8.9/lib/mcollective/matcher/scanner.rb2016-07-21
03:53:53.0 +1000
@@ -65,7 +65,6 @@
current_token_value = ""
j = @token_index
escaped = false
-escaped_with = ""
begin
if (@arguments[j] == "/")
@@ -117,47 +116,46 @@
break
end
- if @arguments[j+1] == "("
+ if @arguments[j] == "("
func = true
-be_greedy = true
- end
-
- if @arguments[j+1] == '"' || @arguments[j+1] == "'"
-func = false
-be_greedy = true
-escaped = true
-escaped_with = @arguments[j+1]
- end
- current_token_value << @arguments[j]
+current_token_value << @arguments[j]
+j += 1
- if be_greedy
-if func
- while !(j+1 >= @arguments.size) && @arguments[j] != ')'
+while j < @arguments.size
+ current_token_value << @arguments[j]
+ if @arguments[j] == ')'
j += 1
-current_token_value << @arguments[j]
+break
end
-else
- j += 2 # step over first "
- @white_spaces += 1
- # identified "..."
- while !(j+1 >= @arguments.size) && @arguments[j] !=
escaped_with
-if @arguments[j] == '\\'
- # eat the escape char but don't add it to the token, or
we
- # end up with \\\"
- @white_spaces += 1
- j += 1
- escaped = true
+ j += 1
+end
+ elsif @arguments[j] == '"' || @arguments[j] == "'"
+escaped = true
+
Re: Guessing package version for DLA template
On 2017-03-02, Bálint Réczey wrote: > I have prepared a patch to optionally prepare the template using: > bin/gen-DSA package.changes That looks OK, just merge it and we can adapt it later on if needed (for instance it would need to handle multiple changes files, for when both stable and oldstable need to be updated by the same team). Cheers, --Seb
Re: Guessing package version for DLA template
Hi Balint, Seb, On Thu, Mar 02, 2017 at 06:53:14AM +, Sébastien Delafond wrote: > On 2017-03-02, Bálint Réczey wrote: > > I have prepared a patch to optionally prepare the template using: > > bin/gen-DSA package.changes > > That looks OK, just merge it and we can adapt it later on if needed (for > instance it would need to handle multiple changes files, for when both > stable and oldstable need to be updated by the same team). Ack, I tested it as well locally with one example, and worked indeed quite well. Missing bit would be as Seb stated to handle the case when we have to support both stable and oldstable, but maybe that can be improved later on. I will try to use it on future DSAs. Thanks for your work! Salvatore
munin regression update possibly needed
Hi LTS team, Please CC me on replies. You might want to double check if munin for wheezy needs as well a regression update for the zooming problem, #856455. But please be aware that the DSA-3794-2 update which I issued introduces another regression, #856536 which should not be introduced as well for wheezy. Regards, Salvatore
