rails-html-sanitizer 1.0.3: Two broken tests with loofah 2.2.1 (CVE-2018-8048)

[Georg Faerber]

Hi Kasper,

We would like to fix CVE-2018-8048, which was assigned some days ago, to
loofah. A fix was released to address a potential XSS vulnerability
caused by libxml2. See [1] and below:

On 18-03-22 01:04:23, Cédric Boutillier wrote:
> On Wed, Mar 21, 2018 at 11:35:57PM +0100, Georg Faerber wrote:
> > Please review / upload ruby-loofah 2.2.1-1, which fixes
> > CVE-2018-8048.  Changes pushed to git in branch d/2.2.1-1.
> 
> This new version breaks two tests in ruby-rails-html-sanitizer (some
> spaces changed in the output). I didn't check if there was some update
> for this package which would reflect this.

Any input on this? Would it be possible to release a new version
addressing this?

Thanks,
cheers,
Georg


[1] https://github.com/flavorjones/loofah/issues/144


signature.asc
Description: Digital signature

Re: simple helper scripts: vcs-salsa, standards-version, debhelper-compat

[Georg Faerber]

Hi,

On 18-03-20 11:25:12, Cédric Boutillier wrote:
> I added simple scripts in the meta repo, which automate boring tasks:

Nice! :)

> standards-version:
>   update Standards-Version to the latest policy version

This breaks if the file is not available. I'll add a check to catch
this.

> If you have similar scripts which could help, please share :)

I really really would like to join forces on this. Automate all the
things, is, IMHO, not only valid for the sysadmins among us, but in
general: It reduces errors, gets rid of manual, boring work, and is much
more faster than doing things manually.

Therefore: Thanks a lot!

Cheers,
Georg


signature.asc
Description: Digital signature

Re: RFS: ruby-loofah 2.2.1-1 (CVE-2018-8048)

[Chris Hofstaedtler]

* Georg Faerber  [180322 01:29]:
> On 18-03-22 01:04:23, Cédric Boutillier wrote:
> > Can you also take care of applying the patch to the version currently
> > in stable and contact the security team for a proposed update for
> > stretch?
> 
> Actually, aren't proposed uploads targeted at point releases? If so,
> this might take a while, as the last one just happened recently.
> Shouldn't this be instead a "straight" upload by the security team? I
> still would create the patch.

This decision is in the hands of the security team. In any case you
can prepare the patch/debdiff, and, if they are not going to upload
it, retarget to stretch (instead of stretch-security).

To save some work you can try asking on #debian-security first :-)

Chris

Re: RFS: ruby-loofah 2.2.1-1 (CVE-2018-8048)

[Georg Faerber]

On 18-03-22 01:04:23, Cédric Boutillier wrote:
> Can you also take care of applying the patch to the version currently
> in stable and contact the security team for a proposed update for
> stretch?

Actually, aren't proposed uploads targeted at point releases? If so,
this might take a while, as the last one just happened recently.
Shouldn't this be instead a "straight" upload by the security team? I
still would create the patch.


signature.asc
Description: Digital signature

Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve

[Georg Faerber]

On 18-03-21 23:34:50, Cédric Boutillier wrote:
> On Wed, Mar 21, 2018 at 11:29:33PM +0300, Hleb Valoshka wrote:
> > On 3/21/18, Cédric Boutillier  wrote:
> 
> > > Is it "normal" that ruby-gettext-setup tests fail with the new
> > > ruby-gettext? They seem to pass with the current version on
> > > ci.debian.net.
> 
> > I've checked ruby-gettext-setup and can say that it doesn't actually
> > use anything from gettext gem, only from fast-gettext. So its test
> > failures caused by something else, not the new gettext version.
> 
> Ok. I've just uploaded ruby-gettext.

FWIW: I've updated ruby-gettext-setup five days ago to the latest
upstream release, it was severely outdated, and especially broke
completely puppet, making the later next to unusable. Are you using a
current testbed?

Cheers,
Georg


signature.asc
Description: Digital signature

RFS: ruby-loofah 2.2.1-1 (CVE-2018-8048)

[Georg Faerber]

Hi all,

Please review / upload ruby-loofah 2.2.1-1, which fixes CVE-2018-8048.
Changes pushed to git in branch d/2.2.1-1.

Thanks,
cheers,
Georg


signature.asc
Description: Digital signature

Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve

[Cédric Boutillier]

On Wed, Mar 21, 2018 at 11:29:33PM +0300, Hleb Valoshka wrote:
> On 3/21/18, Cédric Boutillier  wrote:

> > Is it "normal" that ruby-gettext-setup tests fail with the new
> > ruby-gettext? They seem to pass with the current version on
> > ci.debian.net.

> I've checked ruby-gettext-setup and can say that it doesn't actually
> use anything from gettext gem, only from fast-gettext. So its test
> failures caused by something else, not the new gettext version.

Ok. I've just uploaded ruby-gettext.

> > I was wondering if instead of conflicting with ruby-dep-selector, it was
> > possible to deactivate this engine in ruby-solve, just by forbidding the
> > use of :gecode key in solver_for_engine method in lib/solve.rb.

> I thought about this, maybe patching solve is a better idea, but see
> above. The only solve user is berkshelf so it seems better to patch it
> instead.

I maybe a bit picky here, but I think that Conflicts: is not
semantically right in this situation.
I would rather see this minimal patch to disallow gecode engine in
ruby-solve, and a Breaks: berkshelf (<= current version)
instead of the Conflicts: ruby-dep-selector.
I think it would ease a lot upgrade path if we just prevent ruby-solve
from using ruby-dep-selector instead of preventing coinstalling them.

Cheers,

Cédric


signature.asc
Description: PGP signature

Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve

[Hleb Valoshka]

On 3/21/18, Cédric Boutillier  wrote:

> Is it "normal" that ruby-gettext-setup tests fail with the new
> ruby-gettext? They seem to pass with the current version on
> ci.debian.net.

I've checked ruby-gettext-setup and can say that it doesn't actually
use anything from gettext gem, only from fast-gettext. So its test
failures caused by something else, not the new gettext version.

> For ruby-solve, I couldn't run the tests for berkshelf with the new
> ruby-solve in autopkgtest, because it would complain about unsatisfiable
> dependencies.

Berkshelf by default it uses gecode solver (so it needs to be
patched). And Conflicts header in ruby-solve will prevent its upgrade
if Berkshelf is installed, because the latter has Depends:
ruby-dep-selector.

> I was wondering if instead of conflicting with ruby-dep-selector, it was
> possible to deactivate this engine in ruby-solve, just by forbidding the
> use of :gecode key in solver_for_engine method in lib/solve.rb.

I thought about this, maybe patching solve is a better idea, but see
above. The only solve user is berkshelf so it seems better to patch it
instead.

Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve

[Cédric Boutillier]

ruby-kgio uploaded.


signature.asc
Description: PGP signature