bug#38422: .png files in /gnu/store with executable permissions (555)

bug#38422: .png files in /gnu/store with executable permissions (555)

[Bengt Richter]

Hi Guix,

I was wanting to check on some executable files in the store,
and happened to see some executable .png files ;-/

I suspect they came in when I was playing with icecat
and let it load  a "theme", but I am not sure some didn't
also happen trying to get firefox radio buttons to work ;-/

Anyway, does anyone else get 555 permissions on files like these?
These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.
Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.

Is this zero-day stuff with a nasty somewhere, waiting for referencing by another nasty, or am I being paranoid?
What is the safe way to detoxify this mess? I know I shouldn't directly chmod anything in store, right?

The icecat discussion got moved to mozilla, but in case someone else did whatever I did,
I thought I'd post a heads-up here.
I'll try to cc Mark :)

$ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
--8<---------------cut here---------------start------------->8---
      1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
      1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'
     97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme
      1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'
      1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'
      1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'
      1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'
      1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'
  34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
      1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'
     62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook
      1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'
      1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'
      1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'
      1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'
      1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'
      1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'
      1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'
      1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'
      1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'
      1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'

--8<---------------cut here---------------end--------------->8---

-- 
Regards,
Bengt Richter

bug#38422: .png files in /gnu/store with executable permissions (555)

[Ricardo Wurmus]

Bengt Richter <bokr@bokr.com> writes:

> $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
> --8<---------------cut here---------------start------------->8---
>       1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
>       1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'
>      97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme
>       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'
>       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'
>       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'
>       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'
>       1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'
>   34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
>       1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'
>      62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook
>       1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'
>       1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'
>       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'
>       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'
>       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'
>       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'
>       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'
>       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'
>       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'
>       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'
>
> --8<---------------cut here---------------end--------------->8---

Maybe I’m missing something, but none of the above are PNGs.
Most of them are executables, others are directories, so having them
executable is expected.

Did I misunderstand?

-- 
Ricardo

bug#38422: .png files in /gnu/store with executable permissions (555)

[zimoun]

Hi,

On Fri, 29 Nov 2019 at 11:43, Ricardo Wurmus <rekado@elephly.net> wrote:

> Maybe I’m missing something, but none of the above are PNGs.
> Most of them are executables, others are directories, so having them
> executable is expected.

I am not sure to understand the issue but for example:

   find /gnu/store/ -type f -perm /111 -iname '*.png' -print

returns this file:

/gnu/store/xj7kn8vw1nkcg7qpl3491b831p88i9wn-python-coverage-4.5.3/lib/python3.7/site-packages/coverage/htmlfiles/keybd_open.png


Hope that helps,
simon

bug#38422: .png files in /gnu/store with executable permissions (555)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 3731 bytes --]

Bengt, Ricardo,

I see similar results here with ‘guix install moka-icon-theme’, 
and I'm sure the rest of my (and everyone's) store is full of 
misperm'd files too.  It's kind of generally known.

This seems to be particularly common in Meson packages: for some 
reason, Meson installs everything as executable by default.

Bengt Richter 写道：
> Is this zero-day stuff with a nasty somewhere, waiting for 
> referencing
> by another nasty, or am I being paranoid?

What's the threat model there?  Respectfully, I think you might 
be, but maybe I'm naive…

Otherwise I consider this a merely cosmetic issue, but we still 
welcome fixes for those!

Checking whether Meson behaves differently on other distributions 
would be a good start.

Ricardo Wurmus 写道：
> Bengt Richter <bokr@bokr.com> writes:
>
>> $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a 
>> %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
>> --8<---------------cut 
>> here---------------start------------->8---
>>       1 x 
>>       '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
>>       1 x 
>>       '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'
>>      97 x 
>>      '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme
>>       1 x 
>>       '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'
>>       1 x 
>>       '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'
>>       1 x 
>>       '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'
>>       1 x 
>>       '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'
>>       1 x 
>>       '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'
>>   34143 x 
>>   '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
>>       1 x 
>>       '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'
>>      62 x 
>>      '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook
>>       1 x 
>>       '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'
>>       1 x 
>>       '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'
>>       1 x 
>>       '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'
>>       1 x 
>>       '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'
>>       1 x 
>>       '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'
>>       1 x 
>>       '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'
>>       1 x 
>>       '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'
>>       1 x 
>>       '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'
>>       1 x 
>>       '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'
>>       1 x 
>>       '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'
>>
>> --8<---------------cut 
>> here---------------end--------------->8---
>
> Maybe I’m missing something, but none of the above are PNGs.
> Most of them are executables, others are directories, so having 
> them
> executable is expected.

Bengt's clever pipeline tallies the number of executable *png 
files in each top-level store directory.  It does not include 
directories.

It's true that the '*png' above should be replaced with '*.png', 
but these /bin files are just the very noisy outliers.

The meat is in:

> 34143 x 
> '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme

i.e. 34143 executable '*png' files in that directory alone.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#38422: .png files in /gnu/store with executable permissions (555)

[Bengt Richter]

Hi Ricardo,

On +2019-11-29 10:49:06 +0100, Ricardo Wurmus wrote:
> 
> Bengt Richter <bokr@bokr.com> writes:
> 
> > $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
> > --8<---------------cut here---------------start------------->8---
> >       1 x '/gnu/store/.links/1s94fymqj8xba55rg8xbdni9a215kxsxkddyh2qyb7y6fl7srpng'
> >       1 x '/gnu/store/.links/05dsk06ffdwgjdqgsy03zhnsrcd44yyi8ylk9qyb1a3n89aplpng'
> >      97 x '/gnu/store/jf7i57glqykwgm1k7zb5k8x6f1yd47l8-faba-icon-theme
> >       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdparttopng'
> >       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gdtopng'
> >       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/webpng'
> >       1 x '/gnu/store/k83hj06qj142xv6rqpfh3mcdf3149q09-gd-2.2.5/bin/gd2topng'
> >       1 x '/gnu/store/x9c77i6r5fmarslij6ng81awgrxblplm-texlive-bin-20180414/bin/dvipng'
> >   34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
> >       1 x '/gnu/store/7mxkdn6cp7x8sac49p2g80qw5j1aavi3-texlive-20180414/bin/dvipng'
> >      62 x '/gnu/store/6d79d8za76pj5f2flhckpmdvdgqhqxaa-docbook-xsl-1.79.1/xml/xsl/docbook
> >       1 x '/gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/dvipng'
> >       1 x '/gnu/store/9w1hi2hr4zczc5jd5r2xmff9zf4gwc1n-texlive-union-49435/bin/dvipng'
> >       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdparttopng'
> >       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gdtopng'
> >       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/webpng'
> >       1 x '/gnu/store/5hv33gy8w247v3dcf4dfa8p0ijkmiz5x-gd-2.2.5/bin/gd2topng'
> >       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdparttopng'
> >       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gdtopng'
> >       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/webpng'
> >       1 x '/gnu/store/9jgmsnx36wv8ymgalwd1zlmq3z34bqf0-gd-2.2.5/bin/gd2topng'
> >
> > --8<---------------cut here---------------end--------------->8---
> 
> Maybe I’m missing something, but none of the above are PNGs.
> Most of them are executables, others are directories, so having them
> executable is expected.
> 
> Did I misunderstand?
>

No, you just didn't see it ;-)
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ Sorry I didn't highlight well enough that I had trimmed off the full paths that ended in .png │
│ in what you snipped out above the above (see box below):                                      │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

--8<----(the part you snipped out)-----------cut here---------------start------------->8---
Hi Guix,

I was wanting to check on some executable files in the store,
and happened to see some executable .png files ;-/

I suspect they came in when I was playing with icecat
and let it load  a "theme", but I am not sure some didn't
also happen trying to get firefox radio buttons to work ;-/

Anyway, does anyone else get 555 permissions on files like these?
┌───────────────────────────────────────────────────────────────────────────────────────────┐
│ These are all *.png files with 555 permissons, but I trimmed back to see common prefixes. │
│ Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.         │
└───────────────────────────────────────────────────────────────────────────────────────────┘

Is this zero-day stuff with a nasty somewhere, waiting for referencing by another nasty, or am I being paranoid?
What is the safe way to detoxify this mess? I know I shouldn't directly chmod anything in store, right?

The icecat discussion got moved to mozilla, but in case someone else did whatever I did,
I thought I'd post a heads-up here.
I'll try to cc Mark :)
--8<----(the part you snipped out)-----------cut here---------------end--------------->8---


Note the cut -d '-' etc from above
--8<---------------cut here---------------start------------->8---
> > $ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|cut -d '-' -f5,6,7,8|less|uniq -c|less
--8<---------------cut here---------------end--------------->8---

I thought the 34143 moka-icon-theme items looked especially iffy, being so many:
--8<---------------cut here---------------start------------->8---
> >   34143 x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme
--8<---------------cut here---------------end--------------->8---

So let's not cut that tail and just grab some of those moka-icon-theme items full length:
$ find /gnu -type f -perm /111 -iname '*png'|xargs stat -c '%a %A %N'|grep moka-icon-theme|head
--8<---------------cut here---------------start------------->8---
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-insync-synced.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-synchronizing.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-insync-synced-callbacks-active.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-insync-syncing.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-dropbox-uptodate.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-readonly.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-important.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-danger.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-web.png'
555 -r-xr-xr-x '/gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0/share/icons/Moka/64x64@2x/emblems/emblem-symbolic-link.png'
--8<---------------cut here---------------end--------------->8---

Some executables ending in png are legit, like conversion programs from something to .png format.

> -- 
> Ricardo
> 

PS. Thinking about it, I'm pretty sure I used normal guix install ... yes:

--8<----(555s were in source tarball)-----------cut here---------------start------------->8---
$ guix package -I|grep -i moka
moka-icon-theme 5.4.0   out     /gnu/store/yg6skr4v6vnj04rm5k9h3pa81mjivba7-moka-icon-theme-5.4.0
$ mkdir ~/my-roots
$ guix build -r ~/my-roots/moka -S moka-icon-theme
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
67.4 MB will be downloaded:
   /gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz
substituting /gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz...
downloading from https://ci.guix.gnu.org/nar/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz...
 moka-icon-theme-5.4.0.tar.gz  64.3MiB                                                                                1.5MiB/s 00:44 [##################] 100.0%

/gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz
$ lsc ~/my-roots/*
                 72 2019-11-29 03:53:27 [@] /home/bokr/my-roots/moka -> /gnu/store/vd3l2qbmdw0i9v9knqjm3q42sfwli2nl-moka-icon-theme-5.4.0.tar.gz
$ tar -tzvf ~/my-roots/moka|egrep -m5 'png$'
lrwxrwxrwx root/root         0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/exit.png -> system-log-out.png
lrwxrwxrwx root/root         0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-lockscreen.png -> system-lock-screen.png
lrwxrwxrwx root/root         0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-logout.png -> system-log-out.png
lrwxrwxrwx root/root         0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-run.png -> system-run.png
lrwxrwxrwx root/root         0 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/gnome-session-reboot.png -> system-restart.png

Oops, those were links, let's try again:

$ tar -tzvf ~/my-roots/moka|egrep -m5 '^[^l].*png$'
-rwxrwxr-x root/root       633 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-lock-screen.png
-rwxrwxr-x root/root       537 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-log-out.png
-rwxrwxr-x root/root       554 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-restart.png
-rwxrwxr-x root/root       549 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-run.png
-rwxrwxr-x root/root       544 2018-06-16 09:06 moka-icon-theme-5.4.0/Moka/16x16/actions/system-shutdown.png
--8<----(555s were in source tarball)-----------cut here---------------end--------------->8---

-- 
Regards,
Bengt Richter

bug#38422: .png files in /gnu/store with executable permissions (555)

[Mark H Weaver]

Hi Bengt,

Bengt Richter <bokr@bokr.com> wrote:
> I was wanting to check on some executable files in the store,
> and happened to see some executable .png files ;-/
> 
> I suspect they came in when I was playing with icecat
> and let it load  a "theme", but I am not sure some didn't
> also happen trying to get firefox radio buttons to work ;-/

Certainly not.  Unless you ran icecat as root, it would not have
sufficient permissions to modify /gnu/store.  Installing a theme or
addon in IceCat, or changing its configuration, modifies files in your
~/.mozilla, not /gnu/store.

> Anyway, does anyone else get 555 permissions on files like these?
> These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.
> Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.

I looked at docbook-xsl-1.79.1, since I happen to have it installed on
my system.  Some of the *.png files are incorrectly given executable
permissions within the upstream source tarball itself.  I guess it's
probably the same issue with moka-icon-theme and faba-icon-theme, since
I don't see anything in our package code that would have done it.

Most of the entries in your list that end with "png" but not ".png" are
actually programs whose name ends with "png", so they *should* be
executable.  The files in /gnu/store/.links that end with "png" are just
random chance, because the file names themselves are hashes.

> Is this zero-day stuff with a nasty somewhere, waiting for referencing
> by another nasty, or am I being paranoid?

I think you're being paranoid in this case.  I don't see anything here
to be concerned about, just some minor sloppiness by 3 upstreams.

> What is the safe way to detoxify this mess?

The proper solution is to send bug reports to the upstream developers of
docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix
the permissions of the *.png files in their source tarballs.

> I know I shouldn't directly chmod anything in store, right?

Right, *never* modify files in /gnu/store directly.

> The icecat discussion got moved to mozilla,

Which discussion are you referring to?

     Thanks,
       Mark

bug#38422: .png files in /gnu/store with executable permissions (555)

[Bengt Richter]

Hi Mark.

On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
> Hi Bengt,
> 
> Bengt Richter <bokr@bokr.com> wrote:
> > I was wanting to check on some executable files in the store,
> > and happened to see some executable .png files ;-/
> > 
> > I suspect they came in when I was playing with icecat
> > and let it load  a "theme", but I am not sure some didn't
> > also happen trying to get firefox radio buttons to work ;-/
> 
> Certainly not.  Unless you ran icecat as root, it would not have
> sufficient permissions to modify /gnu/store.  Installing a theme or
> addon in IceCat, or changing its configuration, modifies files in your
> ~/.mozilla, not /gnu/store.
>
Yes, d'oh ;-) I was writing the "PS." in my reply to Ricardo probably
while you were writing this :) There I extracted some
guix build -S tarball content and showed that that was the perm source.

> > Anyway, does anyone else get 555 permissions on files like these?
> > These are all *.png files with 555 permissons, but I trimmed back to see common prefixes.
> > Obviously the moka-con-theme was most of it, but also faba and docbook look iffy.
> 
> I looked at docbook-xsl-1.79.1, since I happen to have it installed on
> my system.  Some of the *.png files are incorrectly given executable
> permissions within the upstream source tarball itself.  I guess it's
> probably the same issue with moka-icon-theme and faba-icon-theme, since
> I don't see anything in our package code that would have done it.
Yes, I found the bad perms in the tarball likewise.

> 
> Most of the entries in your list that end with "png" but not ".png" are
> actually programs whose name ends with "png", so they *should* be
> executable.  The files in /gnu/store/.links that end with "png" are just
> random chance, because the file names themselves are hashes.
Yeah, I realized. Could have done a cleaner job, but I was also curious
how many legit executables ended in png.

> 
> > Is this zero-day stuff with a nasty somewhere, waiting for referencing
> > by another nasty, or am I being paranoid?
> 
> I think you're being paranoid in this case.  I don't see anything here
> to be concerned about, just some minor sloppiness by 3 upstreams.
>
IIRC I did read of jpeg images being used to obfuscate call-home info
in some tricky malware, so anomalies in the same kind of file triggered
the question of whether it could be accidentally on purpose ;-/

> > What is the safe way to detoxify this mess?
> 
> The proper solution is to send bug reports to the upstream developers of
> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix
> the permissions of the *.png files in their source tarballs.
>
That I haven't done. Is there a standard way to do it?
"guix show moka-icon-theme" tells me homepage, but it would be nice
to have a guix show --verbose that would show bug reporting info :)

> > I know I shouldn't directly chmod anything in store, right?
> 
> Right, *never* modify files in /gnu/store directly.
> 
> > The icecat discussion got moved to mozilla,
> 
> Which discussion are you referring to?
> 

Sorry, wrong zilla ;-p

https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00686.html

>      Thanks,
>        Mark

-- 
Regards,
Bengt Richter

bug#38422: .png files in /gnu/store with executable permissions (555)

[Mark H Weaver]

Hi Bengt,

Bengt Richter <bokr@bokr.com> writes:

> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
>> The proper solution is to send bug reports to the upstream developers of
>> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix
>> the permissions of the *.png files in their source tarballs.
>>
> That I haven't done. Is there a standard way to do it?

No.

> "guix show moka-icon-theme" tells me homepage, but it would be nice
> to have a guix show --verbose that would show bug reporting info :)

It would be nice, but it would also be an enormous amount of work.
First we'd need to devise a way to represent that information, and then
we'd need to add it to each of our 10K+ packages.  It would also be an
additional job to do when adding new packages.  I'm not sure it's worth
all that work.  We already record the home page, and from there it's
usually not much work to find how to report bugs.  In cases where it
_is_ difficult to find out how to report bugs, that's arguably a problem
that should be fixed upstream.

What do you think?

      Regards,
        Mark

bug#38422: .png files in /gnu/store with executable permissions (555)

[Brett Gilio]

Mark H Weaver <mhw@netris.org> writes:

> [...] In cases where it
> _is_ difficult to find out how to report bugs, that's arguably a problem
> that should be fixed upstream.
>
> What do you think?
>
>       Regards,
>         Mark
>
>
>

Agreed 100% with Mark.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38422: .png files in /gnu/store with executable permissions (555)

[Julien Lepiller]

Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit :
>Hi Bengt,
>
>Bengt Richter <bokr@bokr.com> writes:
>
>> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
>>> The proper solution is to send bug reports to the upstream
>developers of
>>> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to
>fix
>>> the permissions of the *.png files in their source tarballs.
>>>
>> That I haven't done. Is there a standard way to do it?
>
>No.
>
>> "guix show moka-icon-theme" tells me homepage, but it would be nice
>> to have a guix show --verbose that would show bug reporting info :)
>
>It would be nice, but it would also be an enormous amount of work.
>First we'd need to devise a way to represent that information, and then
>we'd need to add it to each of our 10K+ packages.  It would also be an
>additional job to do when adding new packages.  I'm not sure it's worth
>all that work.  We already record the home page, and from there it's
>usually not much work to find how to report bugs.  In cases where it
>_is_ difficult to find out how to report bugs, that's arguably a
>problem
>that should be fixed upstream.
>
>What do you think?
>
>      Regards,
>        Mark

Also, we should not encourage people to report bugs upstream directly. We have to evaluate whether the bug is on our side or theirs first to not drown them in useless bug reports :)

bug#38422: .png files in /gnu/store with executable permissions (555)

[Bengt Richter]

On +2019-11-30 08:45:09 +0100, Julien Lepiller wrote:
> Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit :
> >Hi Bengt,
> >
> >Bengt Richter <bokr@bokr.com> writes:
> >
> >> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
> >>> The proper solution is to send bug reports to the upstream
> >developers of
> >>> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to
> >fix
> >>> the permissions of the *.png files in their source tarballs.
> >>>
> >> That I haven't done. Is there a standard way to do it?
> >
> >No.
> >
> >> "guix show moka-icon-theme" tells me homepage, but it would be nice
> >> to have a guix show --verbose that would show bug reporting info :)
> >
┌───────────────────────────────────────────────────────────────────────┐
│ > >It would be nice, but it would also be an enormous amount of work. │
└───────────────────────────────────────────────────────────────────────┘
> >First we'd need to devise a way to represent that information, and then
> >we'd need to add it to each of our 10K+ packages.  It would also be an
> >additional job to do when adding new packages.  I'm not sure it's worth
> >all that work.  We already record the home page, and from there it's
> >usually not much work to find how to report bugs.  In cases where it
> >_is_ difficult to find out how to report bugs, that's arguably a
> >problem
> >that should be fixed upstream.
> >
┌──────────────────────────┐
│ I think you are right :) │
├──────────────────────────┤
│ > >What do you think?    │
│ > >                      │
│ > >      Regards,        │
│ > >        Mark          │
└──────────────────────────┘
> 
┌──────────────────────────────────────────────────────────────┐
│  I think you are also right -- I withdraw my suggestion :)   │
├──────────────────────────────────────────────────────────────┤
│ > Also, we should not encourage people to report bugs        │
│ upstream directly. We have to evaluate whether the bug is on │
│ our side or theirs first to not drown them in useless bug    │
│ reports :)                                                   │
└──────────────────────────────────────────────────────────────┘

Hm, this seems like it could be important for good relations with upstream?

Should there be an official _distilled and filtered-for-upstream_
git bug repo that guix developers populate and upstream devs
(and anyone) can pull and grep the log of for their projects?

I could imagine (hallucinate ? :) some benfits:

1. First of all, we can all determine easily if there has been
   an "official" report from guix to upstream, to avoid even bothering
   guix developers.
2. If upstream devs know reports have been considered important enough
   by guix developers to be put in the repo, they might pay more attention :)
   There is a lot of tl;dr discussion in many bug-reporting logs, so upstream
   would probably appreciate having curated reports.
3. The log would be a record. Commit hashes would become precise references.
4. To keep the main bug info stream clear of speculative chatty stuff
   (though this sometimes contains critical clues, and belongs somewhere)
   the repo could contain (per major upstream?) files for commentary or
   miscellaneous that guix devs might want to pass on, but not clutter
   the main report with. Of course urls into bugzilla etc can be useful
   as concise see-further refs. All misc stuff optional.
4. The work flow for developers already exists for accepting things
   into the guix package repo, so no major new patterns for everyone to learn.
5. Anyone interested could clone the repo and pull to it for "guix-official"
   bug reporting status.   

WDYT?
-- 
Regards,
Bengt Richter

bug#38422: .png files in /gnu/store with executable permissions (555)

[zimoun]

On Sat, 30 Nov 2019 at 21:09, Bengt Richter <bokr@bokr.com> wrote:

> Should there be an official _distilled and filtered-for-upstream_
> git bug repo that guix developers populate and upstream devs
> (and anyone) can pull and grep the log of for their projects?

The Guix bug database is public and can be browsed for example here
[1] or [2]. Yes, it is not friendly for upstream developer and one
needs some Guix knowledge to correctly find what one is looking for.
Debian has more friendly entry point: the package Tracker [3]. And the
webpage [4] should be improved to report our bug etc. (as Debian is
doing).

(Note that the Guix-HPC search interface is better but currently down.)

[1] http://issues.guix.gnu.org/
[2] https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix;max-bugs=100;base-order=1;bug-rev=1
[3] https://tracker.debian.org/pkg/gmsh
[4] http://guix.gnu.org/packages/gmsh-2.16.0/



All the best,
simon

bug#38422: Bug status? '.png' files with executable permissions

[zimoun]

Dear Bengt,

The bug report [1] points out files with unexpected permission; based
on extension filename.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422


It is not an security issue or the Guix packager did not carefully
check the validity of these files.

If you are security paranoid, you *have to* check by yourself all the
files using "guix build -S" because in paranoid mode you cannot trust
Guix packagers (and Guix committers neither).


In normal mode, 2 options:

 a- propose a patch to change the permission for each offending package
 b- report upstream

Well, at least  these 3 packages docbook-xsl, faba-icon-theme, and
moka-icon-theme comes with unexpected .png file permission.


On the long term, I am not convinced that adding automatic check and
permission change based on filename extension would really add Quality
Assurance. Because we are speaking about quality, not security.


I am inclined to close this bug. What do you think?

All the best,
simon

bug#38422: Bug status? '.png' files with executable permissions

[Bengt Richter]

Hi zimoun,

On +2020-01-22 01:22:45 +0100, zimoun wrote:
> Dear Bengt,
> 
> The bug report [1] points out files with unexpected permission; based
> on extension filename.
> 
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422
> 
> 
> It is not an security issue or the Guix packager did not carefully
> check the validity of these files.
> 
> If you are security paranoid, you *have to* check by yourself all the
> files using "guix build -S" because in paranoid mode you cannot trust
> Guix packagers (and Guix committers neither).
> 
> 
> In normal mode, 2 options:
> 
>  a- propose a patch to change the permission for each offending package
>  b- report upstream
> 
> Well, at least  these 3 packages docbook-xsl, faba-icon-theme, and
> moka-icon-theme comes with unexpected .png file permission.
> 
> 
> On the long term, I am not convinced that adding automatic check and
> permission change based on filename extension would really add Quality
> Assurance. Because we are speaking about quality, not security.
> 
> 
> I am inclined to close this bug. What do you think?
> 
> All the best,
> simon

Ok with me to close, thanks.

-- 
Regards,
Bengt Richter

bug#38422: Bug status? '.png' files with executable permissions

[zimoun]

close 38422
stop

bug#38422:

[zimoun]

tags 38422 notabug
quit