Add murmur.

Add murmur.

[contact.ng0]

This patch adds an proposed change to mumble, murmur as an output.
Murmur is the server of mumble. I tried to use an inherit package first, but the amount of code for the minor difference between mumble and murmur is not worth the length of a new package.
I'm not sure it murmurd needs the "/lib" of output:out (mumble) at runtime,
in the absence of a possibility to test this, we can onl figure out once a
service for murmur is written.

[PATCH] gnu: mumble: Add 'murmur' output.

[contact.ng0]

From: ng0 <contact.ng0@cryptolab.net>

* gnu/packages/telephony.scm (mumble): Add new output 'murmur'.
[arguments]: Add "no-ice" to config phase.
---
 gnu/packages/telephony.scm | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index c393caace..ce5d276f5 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -5,7 +5,7 @@
 ;;; Copyright © 2015, 2016 Efraim Flashner <efraim@flashner.co.il>
 ;;; Copyright © 2016 Lukas Gradl <lgradl@openmailbox.org>
 ;;; Copyright © 2016 Francesco Frassinelli <fraph24@gmail.com>
-;;; Copyright © 2016 ng0 <ng0@libertad.pw>
+;;; Copyright © 2016, 2017 ng0 <contact.ng0@cryptolab.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -353,7 +353,7 @@ address of one of the participants.")
                              (string-append "CONFIG+="
                                             (string-join
                                              (list "no-update"
-                                                   "no-server"
+                                                   "no-ice"
                                                    "no-embed-qt-translations"
                                                    "no-bundled-speex"
                                                    "pch"
@@ -377,6 +377,11 @@ address of one of the participants.")
          (replace 'install ; install phase does not exist
            (lambda* (#:key inputs outputs #:allow-other-keys)
              (let* ((out (assoc-ref outputs "out"))
+                    (murmur (assoc-ref outputs "murmur"))
+                    (mbin (string-append murmur "/bin"))
+                    (metc (string-append murmur "/etc/murmur"))
+                    (mdbus (string-append murmur "/etc/dbus-1/system.d/"))
+                    (mman (string-append murmur "/share/man/man1"))
                     (bin (string-append out "/bin"))
                     (services (string-append out "/share/services"))
                     (applications (string-append out "/share/applications"))
@@ -390,6 +395,13 @@ address of one of the participants.")
                (install-file "icons/mumble.svg" icons)
                (install-file "man/mumble-overlay.1" man)
                (install-file "man/mumble.1" man)
+               ;; Murmur
+               (install-file "release/murmurd" mbin)
+               (install-file "scripts/murmur.ini.system" metc)
+               (rename-file (string-append metc "/murmur.ini.system")
+                            (string-append metc "/murmur.ini"))
+               (install-file "scripts/murmur.conf" mdbus)
+               (install-file "man/murmurd.1" mman)
                (for-each (lambda (file) (install-file file lib))
                          (find-files "." "\\.so\\."))
                (for-each (lambda (file) (install-file file lib))
@@ -410,6 +422,8 @@ address of one of the participants.")
        ("pulseaudio" ,pulseaudio)))
     (native-inputs
      `(("pkg-config" ,pkg-config)))
+    (outputs '("out"      ; The client
+               "murmur")) ; The server
     (synopsis "Low-latency, high quality voice chat software")
     (description
      "Mumble is an low-latency, high quality voice chat
-- 
2.11.0

Re: Add murmur.

[ng0]

contact.ng0@cryptolab.net writes:

> This patch adds an proposed change to mumble, murmur as an output.
> Murmur is the server of mumble. I tried to use an inherit package first, but the amount of code for the minor difference between mumble and murmur is not worth the length of a new package.
> I'm not sure it murmurd needs the "/lib" of output:out (mumble) at runtime,
> in the absence of a possibility to test this, we can onl figure out once a
> service for murmur is written.

Update:
I just ran murmurd and connected to myself (127.0.0.1) and
neither murmurd nor mumble client threw errors at me.
-- 
ng0 . https://www.inventati.org/patternsinthechaos/

Re: Add murmur.

[Ludovic Courtès]

Hi ng0!

contact.ng0@cryptolab.net skribis:

> This patch adds an proposed change to mumble, murmur as an output.

I’m reluctant to “non-standard” outputs like this.  The reason for
multiple outputs should be to reduce the closure size for standards
uses.  What do we gain by not included murmurd in “out” in this case?

Thanks,
Ludo’.

Re: Add murmur.

[ng0]

On 17-02-09 17:50:04, Ludovic Courtès wrote:
> Hi ng0!
> 
> contact.ng0@cryptolab.net skribis:
> 
> > This patch adds an proposed change to mumble, murmur as an output.
> 
> I’m reluctant to “non-standard” outputs like this.  The reason for
> multiple outputs should be to reduce the closure size for standards
> uses.  What do we gain by not included murmurd in “out” in this case?
> 
> Thanks,
> Ludo’.

We remove the server component (murmurd) from the client component
(mumble).  I imagine that if you run murmurd, you will not want mumble
in the same user profile.  And if you run mumble, you probably don't
want murmurd.  The default is a client, adding murmur output is logical.
But this is just my view.. I would not want a server unless I explicitly
expressed my intention to have it

What do you think?


I would even separate the sshd from openssh client part, but that's
another topic.


-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Add murmur.

[Ludovic Courtès]

ng0 <contact.ng0@cryptolab.net> skribis:

> On 17-02-09 17:50:04, Ludovic Courtès wrote:
>> Hi ng0!
>> 
>> contact.ng0@cryptolab.net skribis:
>> 
>> > This patch adds an proposed change to mumble, murmur as an output.
>> 
>> I’m reluctant to “non-standard” outputs like this.  The reason for
>> multiple outputs should be to reduce the closure size for standards
>> uses.  What do we gain by not included murmurd in “out” in this case?
>> 
>> Thanks,
>> Ludo’.
>
> We remove the server component (murmurd) from the client component
> (mumble).  I imagine that if you run murmurd, you will not want mumble
> in the same user profile.  And if you run mumble, you probably don't
> want murmurd.  The default is a client, adding murmur output is logical.
> But this is just my view.. I would not want a server unless I explicitly
> expressed my intention to have it
>
> What do you think?

I think the only reason to separate things usually is size, not
“aesthetics.”  So I’d be in favor of keeping both in the same output if
there’s no size problem.

How does that sound?

Ludo’.

Re: Add murmur.

[ng0]

On 17-02-09 23:50:02, Ludovic Courtès wrote:
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > On 17-02-09 17:50:04, Ludovic Courtès wrote:
> >> Hi ng0!
> >> 
> >> contact.ng0@cryptolab.net skribis:
> >> 
> >> > This patch adds an proposed change to mumble, murmur as an output.
> >> 
> >> I’m reluctant to “non-standard” outputs like this.  The reason for
> >> multiple outputs should be to reduce the closure size for standards
> >> uses.  What do we gain by not included murmurd in “out” in this case?
> >> 
> >> Thanks,
> >> Ludo’.
> >
> > We remove the server component (murmurd) from the client component
> > (mumble).  I imagine that if you run murmurd, you will not want mumble
> > in the same user profile.  And if you run mumble, you probably don't
> > want murmurd.  The default is a client, adding murmur output is logical.
> > But this is just my view.. I would not want a server unless I explicitly
> > expressed my intention to have it
> >
> > What do you think?
> 
> I think the only reason to separate things usually is size, not
> “aesthetics.”  So I’d be in favor of keeping both in the same output if
> there’s no size problem.
>

I don't see my description as aesthetics, but maybe I wasn't clear. It
could theoretically be an security issue, keeping both separated gives
the user a choice of what should be present.

Of course this is a theoretic issue, but the separation of server+client
where applicable when the nature of an application allows it makes sense
to me.

If you don't agree, I can send an updated patch which just adds murmur
to the 'out'.
 
> How does that sound?
> 
> Ludo’.
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Add murmur.

[Marius Bakke]

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

ng0 <contact.ng0@cryptolab.net> writes:

> On 17-02-09 23:50:02, Ludovic Courtès wrote:
>> ng0 <contact.ng0@cryptolab.net> skribis:
>> 
>> > On 17-02-09 17:50:04, Ludovic Courtès wrote:
>> >> Hi ng0!
>> >> 
>> >> contact.ng0@cryptolab.net skribis:
>> >> 
>> >> > This patch adds an proposed change to mumble, murmur as an output.
>> >> 
>> >> I’m reluctant to “non-standard” outputs like this.  The reason for
>> >> multiple outputs should be to reduce the closure size for standards
>> >> uses.  What do we gain by not included murmurd in “out” in this case?
>> >> 
>> >> Thanks,
>> >> Ludo’.
>> >
>> > We remove the server component (murmurd) from the client component
>> > (mumble).  I imagine that if you run murmurd, you will not want mumble
>> > in the same user profile.  And if you run mumble, you probably don't
>> > want murmurd.  The default is a client, adding murmur output is logical.
>> > But this is just my view.. I would not want a server unless I explicitly
>> > expressed my intention to have it
>> >
>> > What do you think?
>> 
>> I think the only reason to separate things usually is size, not
>> “aesthetics.”  So I’d be in favor of keeping both in the same output if
>> there’s no size problem.
>>
>
> Of course this is a theoretic issue, but the separation of server+client
> where applicable when the nature of an application allows it makes sense
> to me.

What does `guix size` say about mumble:murmur compared to mumble:out? If
the server does not depend on any graphical features, I think a separate
output makes sense. mumble alone is ~1GiB.

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

Re: Add murmur.

[ng0]

On 17-02-10 22:54:21, Marius Bakke wrote:
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > On 17-02-09 23:50:02, Ludovic Courtès wrote:
> >> ng0 <contact.ng0@cryptolab.net> skribis:
> >> 
> >> > On 17-02-09 17:50:04, Ludovic Courtès wrote:
> >> >> Hi ng0!
> >> >> 
> >> >> contact.ng0@cryptolab.net skribis:
> >> >> 
> >> >> > This patch adds an proposed change to mumble, murmur as an output.
> >> >> 
> >> >> I’m reluctant to “non-standard” outputs like this.  The reason for
> >> >> multiple outputs should be to reduce the closure size for standards
> >> >> uses.  What do we gain by not included murmurd in “out” in this case?
> >> >> 
> >> >> Thanks,
> >> >> Ludo’.
> >> >
> >> > We remove the server component (murmurd) from the client component
> >> > (mumble).  I imagine that if you run murmurd, you will not want mumble
> >> > in the same user profile.  And if you run mumble, you probably don't
> >> > want murmurd.  The default is a client, adding murmur output is logical.
> >> > But this is just my view.. I would not want a server unless I explicitly
> >> > expressed my intention to have it
> >> >
> >> > What do you think?
> >> 
> >> I think the only reason to separate things usually is size, not
> >> “aesthetics.”  So I’d be in favor of keeping both in the same output if
> >> there’s no size problem.
> >>
> >
> > Of course this is a theoretic issue, but the separation of server+client
> > where applicable when the nature of an application allows it makes sense
> > to me.
> 
> What does `guix size` say about mumble:murmur compared to mumble:out? If
> the server does not depend on any graphical features, I think a separate
> output makes sense. mumble alone is ~1GiB.

As far as I know right now, it does not have any graphical features or
dependencies.

mumble:murmur -> total: 1072.6 MiB
mumble:out    -> total: 1111.2 MiB

So there is a size difference which would justify this output in my
(currently very sleepy and jet-lagged) opinion.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Add murmur.

[Ludovic Courtès]

ng0 <contact.ng0@cryptolab.net> skribis:

> On 17-02-10 22:54:21, Marius Bakke wrote:
>> ng0 <contact.ng0@cryptolab.net> writes:
>> 
>> > On 17-02-09 23:50:02, Ludovic Courtès wrote:
>> >> ng0 <contact.ng0@cryptolab.net> skribis:
>> >> 
>> >> > On 17-02-09 17:50:04, Ludovic Courtès wrote:
>> >> >> Hi ng0!
>> >> >> 
>> >> >> contact.ng0@cryptolab.net skribis:
>> >> >> 
>> >> >> > This patch adds an proposed change to mumble, murmur as an output.
>> >> >> 
>> >> >> I’m reluctant to “non-standard” outputs like this.  The reason for
>> >> >> multiple outputs should be to reduce the closure size for standards
>> >> >> uses.  What do we gain by not included murmurd in “out” in this case?
>> >> >> 
>> >> >> Thanks,
>> >> >> Ludo’.
>> >> >
>> >> > We remove the server component (murmurd) from the client component
>> >> > (mumble).  I imagine that if you run murmurd, you will not want mumble
>> >> > in the same user profile.  And if you run mumble, you probably don't
>> >> > want murmurd.  The default is a client, adding murmur output is logical.
>> >> > But this is just my view.. I would not want a server unless I explicitly
>> >> > expressed my intention to have it
>> >> >
>> >> > What do you think?
>> >> 
>> >> I think the only reason to separate things usually is size, not
>> >> “aesthetics.”  So I’d be in favor of keeping both in the same output if
>> >> there’s no size problem.
>> >>
>> >
>> > Of course this is a theoretic issue, but the separation of server+client
>> > where applicable when the nature of an application allows it makes sense
>> > to me.
>> 
>> What does `guix size` say about mumble:murmur compared to mumble:out? If
>> the server does not depend on any graphical features, I think a separate
>> output makes sense. mumble alone is ~1GiB.
>
> As far as I know right now, it does not have any graphical features or
> dependencies.
>
> mumble:murmur -> total: 1072.6 MiB
> mumble:out    -> total: 1111.2 MiB

And what about the total reported by

  guix size mumble:murmur mumble:out

?

Ludo’.

Re: Add murmur.

[ng0]

On 17-02-11 15:31:15, Ludovic Courtès wrote:
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > On 17-02-10 22:54:21, Marius Bakke wrote:
> >> ng0 <contact.ng0@cryptolab.net> writes:
> >> 
> >> > On 17-02-09 23:50:02, Ludovic Courtès wrote:
> >> >> ng0 <contact.ng0@cryptolab.net> skribis:
> >> >> 
> >> >> > On 17-02-09 17:50:04, Ludovic Courtès wrote:
> >> >> >> Hi ng0!
> >> >> >> 
> >> >> >> contact.ng0@cryptolab.net skribis:
> >> >> >> 
> >> >> >> > This patch adds an proposed change to mumble, murmur as an output.
> >> >> >> 
> >> >> >> I’m reluctant to “non-standard” outputs like this.  The reason for
> >> >> >> multiple outputs should be to reduce the closure size for standards
> >> >> >> uses.  What do we gain by not included murmurd in “out” in this case?
> >> >> >> 
> >> >> >> Thanks,
> >> >> >> Ludo’.
> >> >> >
> >> >> > We remove the server component (murmurd) from the client component
> >> >> > (mumble).  I imagine that if you run murmurd, you will not want mumble
> >> >> > in the same user profile.  And if you run mumble, you probably don't
> >> >> > want murmurd.  The default is a client, adding murmur output is logical.
> >> >> > But this is just my view.. I would not want a server unless I explicitly
> >> >> > expressed my intention to have it
> >> >> >
> >> >> > What do you think?
> >> >> 
> >> >> I think the only reason to separate things usually is size, not
> >> >> “aesthetics.”  So I’d be in favor of keeping both in the same output if
> >> >> there’s no size problem.
> >> >>
> >> >
> >> > Of course this is a theoretic issue, but the separation of server+client
> >> > where applicable when the nature of an application allows it makes sense
> >> > to me.
> >> 
> >> What does `guix size` say about mumble:murmur compared to mumble:out? If
> >> the server does not depend on any graphical features, I think a separate
> >> output makes sense. mumble alone is ~1GiB.
> >
> > As far as I know right now, it does not have any graphical features or
> > dependencies.
> >
> > mumble:murmur -> total: 1072.6 MiB
> > mumble:out    -> total: 1111.2 MiB
> 
> And what about the total reported by
> 
>   guix size mumble:murmur mumble:out


store item                                                       total    self
/gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19         1111.2     5.6   0.5%
/gnu/store/l4as1725kds2rrpz2l1pcfz8bjn256qd-mumble-1.2.19-murmur  1072.6     1.2   0.1%
/gnu/store/gz1hpl2qpjyddczx1pwriwxgd5rdwbxf-qt-4.8.7              1062.7   123.7  11.1%
/gnu/store/b11lvv9x75jgiiw7rpyb53vj8j57jrw6-mysql-5.7.17           561.0   209.2  18.8%
/gnu/store/13cbg5pg4qvgf55qlvi0h1grffr7gfkk-mesa-13.0.3            227.9   128.3  11.5%
/gnu/store/awmx27f02la7sc4s63jxsdczclsf63gj-postgresql-9.5.5       200.5    20.0   1.8%
/gnu/store/nfg59rims86f87q5hasj8ngad3cd9dpa-boost-1.61.0           181.4   120.1  10.8%
/gnu/store/bwjph363njn5nssi0m7klcs17si2zyib-pulseaudio-9.0         161.8     8.3   0.7%
/gnu/store/c7lm5innppxm53bf5w7i99d59kjdyx27-ld-wrapper-0           152.8     0.0   0.0%
/gnu/store/9kmlcadkj7y1ag0lc2jl9dajlq3m90zr-perl-5.24.0            142.2    51.0   4.6%
/gnu/store/y1g6991kxvdk4vxhsq07r5saww30v8dq-gcc-4.9.4              138.6    77.2   6.9%
/gnu/store/wvfi95c1r66k5d2rnin090gy3301x7p9-avahi-0.6.31           130.1     2.4   0.2%
/gnu/store/dcsfk23iwhhsix5icr9lxdcwrd2qb8ks-icu4c-55.1             126.1    34.9   3.1%
/gnu/store/zq2ynjp1hln0jbcwaibyra45p3dxshn1-speech-dispatcher-0.8.5   123.2     1.1   0.1%
/gnu/store/8fabvxy5jgsad1ipn5j420nk5haaj80y-glib-2.50.2            114.6    13.7   1.2%
/gnu/store/v8b2smkb9l4080jnq5m60f700liww3fl-libmng-2.0.3           111.1     1.3   0.1%
/gnu/store/6r1klkng76ssw40c4kv47aib2rbmdssv-lcms-2.6               109.8     1.2   0.1%
/gnu/store/60hvdp3cxn8nr3v1h92vjzv2hfrmfd4q-libtiff-4.0.7          107.8     2.0   0.2%
/gnu/store/6slzn4ixcjlhy3av3biglqfli9pwxcn9-guile-2.0.12           103.4    12.7   1.1%
/gnu/store/ji6b6zhk7l3y7vbjhx7kpnb9v7hlbc6v-eudev-3.2               99.1     7.1   0.6%
/gnu/store/601j6j3fa9nf37vyzy8adcaxcfddw4m1-libsm-1.2.2             91.5     0.3   0.0%
/gnu/store/8b5ffm91zlmm1k5i4kq5qix59v7jm9ln-util-linux-2.28.1       90.6    11.2   1.0%
/gnu/store/4xxd00drj8gjcr84xdfna44qak2vhwmf-binutils-2.27           87.6    49.3   4.4%
/gnu/store/iy28nhsbbfjm1mjksz429zr0r8q8imsz-wayland-1.11.0          87.0     1.4   0.1%
/gnu/store/cgr9z8n3i7kzpsjxnsljby5spvzq836v-libxml2-2.9.4           84.9    10.0   0.9%
/gnu/store/pkv2qqgprp4zxcqfspwwx81qm9lng0da-fontconfig-2.12.1       84.4     2.0   0.2%
/gnu/store/9xfn6q7cxqxaxsv6kgiic9iygl2iv2ci-coreutils-8.25          78.8    14.4   1.3%
/gnu/store/hmc1jiyr29mk9cl2d9j0jwf0dim1q76g-freetype-2.6.3          77.3     2.7   0.2%
/gnu/store/9ylbphjcj07s98srnbq41i2hrz8qwqm1-fftwf-3.3.5             77.0     3.6   0.3%
/gnu/store/9l52vcmb1ambc3ypf7nxn38ac0976yyf-tar-1.29                76.0     2.6   0.2%
/gnu/store/vzlgcmkys1dpw238wq7qb9klb4g84p5l-kmod-23                 75.2     0.3   0.0%
/gnu/store/hin7b7nq2jizd93089zzmjh7i4781j8j-libpng-1.6.25           74.6     0.8   0.1%
/gnu/store/4yg6q1kp856m68arkpqc85hqgbffhpxf-xz-5.2.2                74.5     1.1   0.1%
/gnu/store/fszfgc8xfk6cmxg0kcb7lq02dkkxgdyx-dbus-1.10.14            73.5     1.7   0.2%
/gnu/store/2qxzpfc8hzd1n91xjwyyrq70wl5f5f0i-bash-4.4.0              73.4     5.4   0.5%
/gnu/store/kdflcvx50b31kpnb84vnibqhlx3hj0cc-libxi-1.7.8             72.3     0.6   0.1%
/gnu/store/cc46jh350awm37rq5mpq9dcbna2qd38x-libxvmc-1.0.10          71.8     0.1   0.0%
/gnu/store/1g2fkhn69kr357xwvkbsv6ihprlf7l4x-libxv-1.0.11            71.7     0.1   0.0%
/gnu/store/gfasxl4hff0ly73rqb7vkmjqzzy4vcdk-libxxf86vm-1.1.4        71.7     0.1   0.0%
/gnu/store/gwcmc9klgja71wc44zsb5a84p90napgm-libxext-1.3.3           71.6     0.4   0.0%
/gnu/store/zzldlalgwdin4qgdaz472mydwdp6lzvf-libxrender-0.9.10       71.3     0.1   0.0%
/gnu/store/4ibw0vlg2057qknkzfn2pkwf52mz1ic5-libxdamage-1.1.4        71.3     0.0   0.0%
/gnu/store/0lw5v7fhz4ws6cn0x1ca5fkryy8zf5di-libxfixes-5.0.3         71.3     0.1   0.0%
/gnu/store/dgz1p150n6ffs54qq4rzyh9fx26lrsad-libx11-1.6.4            71.2     5.0   0.4%
/gnu/store/b4al385nxw1mdl4bjkdb4irg4dnsbv6j-protobuf-2.6.1          69.7     8.4   0.8%
/gnu/store/8rpz0r04p9wqm28ash861b43cvql8imz-gcc-5.4.0-lib           68.5    30.2   2.7%
/gnu/store/95p1bzqrz94ahf9rdqh82zfb8fvwjpby-libsndfile-1.0.26       68.3     1.8   0.2%
/gnu/store/iz6rbi4r00jhwzbccnsbq1bbrbdi6h3d-readline-7.0            68.0     1.3   0.1%
/gnu/store/k0x973sjylvi746ib2xn4v1hjp855qq1-readline-7.0            68.0     1.3   0.1%
/gnu/store/liib5wid6rx9rkss78spc7wcqzwb1g2k-openssl-1.0.2j          66.9     5.9   0.5%
/gnu/store/yi8a0206zpqf6qijkn70938jj8l6s87b-ncurses-6.0             66.7     5.7   0.5%
/gnu/store/xydfiifs9slq0wv6n8j6p26icn2ihn88-ncurses-6.0             66.7     5.7   0.5%
/gnu/store/gjvjkcpvpnk6nng4p11ms1gf8mdrzjr2-libxcb-1.11.1           66.2     5.1   0.5%
/gnu/store/qj5sazmlzqbn2nlm7vxj6wjns0mm5x79-libunistring-0.9.6      65.4     4.5   0.4%
/gnu/store/039b1nq0jn2dqykwx5hd1b85sr08fiyc-pcre-8.38               64.3     3.4   0.3%
/gnu/store/4b1dnlxz9rnm6rr8s8d9nl1g3h8zq9v8-libvorbis-1.3.5         64.3     2.8   0.3%
/gnu/store/vsmh5nx41dxzwppd8lmvci403bp0gqv4-flac-1.3.1              63.7     2.2   0.2%
/gnu/store/frxwbfah0l9fr0j398vg3avsrmdfajnj-gmp-6.1.1               63.6     2.6   0.2%
/gnu/store/ykdzlcdyjjfhivids91d1xs36hmzrrp6-gmp-6.1.1               63.6     2.6   0.2%
/gnu/store/gg01c23x1kaa29svhmhlyb6m2ih3hmnb-alsa-lib-1.0.27.1       63.0     2.0   0.2%
/gnu/store/janggjcj3c1a2wf5p6zrgxk50jdy0ibx-libgc-7.4.2             62.7     1.1   0.1%
/gnu/store/aiywpm2w299pk1ps96a8d8qwnwkzfr2g-speex-1.2rc1            62.5     1.0   0.1%
/gnu/store/dp61fnsknp4mi58vnq8jy0wyp0nl2id3-pkg-config-0.29         62.3     1.3   0.1%
/gnu/store/ghhxs3qv8bzbabqy1hnn0drvgsa0c6ci-opus-1.1.4              62.0     1.0   0.1%
/gnu/store/pvlzrp3ckriz4lrz7dsj0x48wxnhjr4h-unixodbc-2.3.4          62.0     1.0   0.1%
/gnu/store/y7lrcb4iqy21vmv1iqjj4fz7y2gfv8s8-libdrm-2.4.68           61.9     0.8   0.1%
/gnu/store/0fv0ppzi9c4an7gy2kb07j0pi1jvfcaf-libjpeg-9b              61.8     0.8   0.1%
/gnu/store/l81by51q2iczg006kx6q44aaadmmg6kp-libjpeg-8d              61.8     0.8   0.1%
/gnu/store/xw9jv7krgy86f5pvnrc77zph25562n1n-acl-2.2.52              61.7     0.4   0.0%
/gnu/store/dgc99gg56wz5i2w6kyb73cj25vm7n9l8-s2tc-1.0                61.6     0.6   0.1%
/gnu/store/ppk2n4xi6pzgchcfzl2p48yj7y4jvnjv-expat-2.2.0             61.6     0.6   0.1%
/gnu/store/30q87g4yfk4vpy58j42g60xijgw1nfll-gdbm-1.12               61.5     0.5   0.0%
/gnu/store/xj685rr28yjrvbc5xxwqh73l9svfj7jx-libice-1.0.9            61.5     0.5   0.0%
/gnu/store/a4wqshv23p3ql7vzfki75i3xnr6yj06h-libogg-1.3.2            61.4     0.5   0.0%
/gnu/store/27ygdlznld2s6bk8mw2hmbhbh517ahaq-libcap-2.24             61.4     0.1   0.0%
/gnu/store/xqig0kjai3psg5pd4ccqyfl2hpc7blxq-libcap-2.24             61.4     0.1   0.0%
/gnu/store/a64w9dq219a8d9k4mfz76mnzph9wsvfj-zlib-1.2.8              61.3     0.4   0.0%
/gnu/store/1lzv35rcby4p1yfvc79qgxi342hbd4x2-sbc-1.3                 61.3     0.3   0.0%
/gnu/store/hgg7bzyq84ny3b1j17c4hkdpx5xmvnw0-attr-2.4.47             61.2     0.2   0.0%
/gnu/store/bkxvn862hrblgnj84vrjhp4s75j77ih0-attr-2.4.47             61.2     0.2   0.0%
/gnu/store/v8i2l75s4xpw6n1hisbrhw1xz28nkgcv-json-c-0.12.1           61.2     0.2   0.0%
/gnu/store/sc8fxjbwfnzn7wyvdyqmkz6a068xnafl-libxdmcp-1.1.2          61.1     0.2   0.0%
/gnu/store/47scmp8vv12kn6gh3r4g4rap328g3404-dotconf-1.3             61.1     0.1   0.0%
/gnu/store/p153bawa5szcv4z6br9jrbwv3zq6qv5m-libffi-3.2.1            61.1     0.1   0.0%
/gnu/store/w0bkj9qh7iqcklm5ld8ghg1ynnzqyv00-libffi-3.2.1            61.1     0.1   0.0%
/gnu/store/lb6z629zg8p5raip9m9k2sris87qsgdn-libltdl-2.4.6           61.1     0.1   0.0%
/gnu/store/9yn89bkl8vcg5rh9dmw3jijciwgrwjls-libltdl-2.4.6           61.1     0.1   0.0%
/gnu/store/rrln8m5ls9h5ghacn1nkv6xcwl30ai06-libpciaccess-0.13.4     61.1     0.1   0.0%
/gnu/store/63fp36w68ydkm35km84g69lc1wckd4hv-libdaemon-0.14          61.1     0.1   0.0%
/gnu/store/ac3q2lp5y4wf6jbxvnk46dn17gfp84yg-libxau-1.0.8            61.0     0.0   0.0%
/gnu/store/a3f9r5pwfp6y81paqrjbq3w5blymcf09-libxshmfence-1.2        61.0     0.0   0.0%
/gnu/store/cdi08kw7r6r684w8mk0xq0dkgpjhfpmd-gcc-4.9.4-lib           61.0    22.7   2.0%
/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0              50.7     5.4   0.5%
/gnu/store/bm0gfw4jkw8gd0vpnnzrb6z0xncrbx3p-readline-7.0            45.3     1.3   0.1%
/gnu/store/hdrli1v7q3107w842s7di8rid82xlfvl-ncurses-6.0             44.0     5.7   0.5%
/gnu/store/vxdm2dqckv3yvwihr4hs6f886v6104az-zlib-1.2.8              38.6     0.4   0.0%
/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24              38.3    36.8   3.3%
/gnu/store/mh3mx042h5ayvg9mgmfln4kwvs102lzp-gs-fonts-8.11            4.5     4.5   0.4%
/gnu/store/rvgmixpmsq5lqr9qflhkm70kg7a4rys2-bash-static-4.4.0        1.4     1.4   0.1%
/gnu/store/idcrs9pr86mw3f5ya87ijhczn6zywxs6-libatomic-ops-7.4.2      0.6     0.6   0.1%
/gnu/store/2pfy48vk10brpjj3a7sga7l7n4ngk4yh-libaio-0.3.110           0.0     0.0   0.0%
total: 1112.3 MiB

 
> ?
> 
> Ludo’.
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

server and client in one package -> security issue (was: Add murmur)

[Hartmut Goebel]

Am 09.02.2017 um 23:50 schrieb Ludovic Courtès:
> I think the only reason to separate things usually is size, not
> “aesthetics.”  So I’d be in favor of keeping both in the same output if
> there’s no size problem.

Separating clients and servers is not an "aesthetic" thing. It's a
matter of security.

One basic rule for hardening systems is: "only install the required
software". If we munge server and clients packages, this obeys this rule.

In my day-business I'm a security consultant (CISSP, CSSLP  and ISO
27001 Lead Implementer). And from my point of view Guix already has a
medium problem of acceptance since it munges development-files and
run-time files into one package - as we do for all libraries. This
already contradicts the above mentioned basic rule.

Now if Guix starts munging server and client components into one
package, this plain disqualifies GuixSD from any security sensitive
system. [*]

[*] OTOH it opens up chances for big business: selling "Secure GuixSD"
to customers.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue (was: Add murmur)

[ng0]

On 17-02-12 13:23:09, Hartmut Goebel wrote:
> Am 09.02.2017 um 23:50 schrieb Ludovic Courtès:
> > I think the only reason to separate things usually is size, not
> > “aesthetics.”  So I’d be in favor of keeping both in the same output if
> > there’s no size problem.
> 
> Separating clients and servers is not an "aesthetic" thing. It's a
> matter of security.
> 
> One basic rule for hardening systems is: "only install the required
> software". If we munge server and clients packages, this obeys this rule.
> 
> In my day-business I'm a security consultant (CISSP, CSSLP  and ISO
> 27001 Lead Implementer). And from my point of view Guix already has a
> medium problem of acceptance since it munges development-files and
> run-time files into one package - as we do for all libraries. This
> already contradicts the above mentioned basic rule.
> 
> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]
> 
> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.
> 
> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel          | h.goebel@crazy-compilers.com               |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 

Exactly why I think we should do this, with a more detailed reasoning.
Thanks!
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: server and client in one package -> security issue (was: Add murmur)

[David Craven]

> And from my point of view Guix already has a medium problem of acceptance
> since it munges development-files and run-time files into one package - as we
> do for all libraries.

By development files I assume you mean header files? I don't see how those can
pose a security problem. Can you elaborate?

> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]

> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.

I think that we provide security on a best effort basis. A high profile target
like a bank or credit card payment service will likely have their own security
team and will use guixsd as a basis for their deployment. We can not do the
work that is the responsibility of an in house sysops team.

Re: Add murmur.

[Ludovic Courtès]

ng0 <contact.ng0@cryptolab.net> skribis:

> On 17-02-11 15:31:15, Ludovic Courtès wrote:
>> ng0 <contact.ng0@cryptolab.net> skribis:

[...]

>> > As far as I know right now, it does not have any graphical features or
>> > dependencies.
>> >
>> > mumble:murmur -> total: 1072.6 MiB
>> > mumble:out    -> total: 1111.2 MiB
>> 
>> And what about the total reported by
>> 
>>   guix size mumble:murmur mumble:out

[...]

> store item                                                       total    self
> /gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19         1111.2     5.6   0.5%
> /gnu/store/l4as1725kds2rrpz2l1pcfz8bjn256qd-mumble-1.2.19-murmur  1072.6     1.2   0.1%

[...]

> total: 1112.3 MiB

For 1.2 MiB, I’d say keep both in the same output.

Could you update the patch accordingly?

Thank you!

Ludo’.

Re: Add murmur.

[ng0]

On 17-02-12 14:37:53, Ludovic Courtès wrote:
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > On 17-02-11 15:31:15, Ludovic Courtès wrote:
> >> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> [...]
> 
> >> > As far as I know right now, it does not have any graphical features or
> >> > dependencies.
> >> >
> >> > mumble:murmur -> total: 1072.6 MiB
> >> > mumble:out    -> total: 1111.2 MiB
> >> 
> >> And what about the total reported by
> >> 
> >>   guix size mumble:murmur mumble:out
> 
> [...]
> 
> > store item                                                       total    self
> > /gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19         1111.2     5.6   0.5%
> > /gnu/store/l4as1725kds2rrpz2l1pcfz8bjn256qd-mumble-1.2.19-murmur  1072.6     1.2   0.1%
> 
> [...]
> 
> > total: 1112.3 MiB
> 
> For 1.2 MiB, I’d say keep both in the same output.
> 
> Could you update the patch accordingly?
> 
> Thank you!
> 
> Ludo’.
> 

Okay. I prefer to wait for the outcome of the discussion around
server+client merging. I'm in favor of separating for the reasons Harmut
mentioned.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Add murmur.

[David Craven]

> Okay. I prefer to wait for the outcome of the discussion around
> server+client merging. I'm in favor of separating for the reasons Harmut
> mentioned.

This is a free software community. Anyone that needs to assert his authority
with external certifications rather than actions and sound reasoning is in the
wrong place here.

Re: Add murmur.

[ng0]

On 17-02-12 14:57:05, David Craven wrote:
> > Okay. I prefer to wait for the outcome of the discussion around
> > server+client merging. I'm in favor of separating for the reasons Harmut
> > mentioned.
> 
> This is a free software community. Anyone that needs to assert his authority
> with external certifications rather than actions and sound reasoning is in the
> wrong place here.
> 

You read too much between the lines in my words.

I'm not counting on the certifications of Harmut. I simply agree with
the reasoning that no client and server should be combined if possible
to limit the attack surface. That's all.
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Add murmur.

[David Craven]

> You read too much between the lines in my words.

> I'm not counting on the certifications of Harmut. I simply agree with
> the reasoning that no client and server should be combined if possible
> to limit the attack surface. That's all.

That may be true. It was my intention to back Ludo. I think that it is a minor
issue at best, since anything that isn't accessible over the network or running
with any sort of privileges is not very useful.

An attack usually involves exploiting a service for remote code
execution, followed
by privilege escalation and finally securing access to the system and
cleaning up
traces.

This is an unprivileged binary on a server, and it isn't even running.
Exploiting any
bugs in the client would require starting the client first. This means
that an attacker
has already gained physical access or is able to perform remote code execution.

This hypothetical attacker is trying to escalate privileges. I don't
see how starting
an unprivileged process would help with that.

But then again - I'm not an expert and don't have any credentials - so
I'd be interested
to know if there is a way of exploiting this.

Re: server and client in one package -> security issue

[Hartmut Goebel]

Am 12.02.2017 um 13:53 schrieb David Craven:
> By development files I assume you mean header files? I don't see how those can
> pose a security problem. Can you elaborate?

Yes, I meant header files, but also pkgconfig files and all this stuff
(including documentation). Having this (and compilers, etc.) available
on the target machine makes it *much* easier for an intruder to compile
attack tools for malware on the target. If these are missing, the
intruder needs to collect a lot of information first to be able to build
tools for the target.

Of course this is not a silver bullet, but it one piece of protection.
Like a lock on the door: It may take the burglar only 2 Minutes to open
it, but less skilled ones may be discouraged. Or these 2 Minutes may
give you some advantage.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Add murmur.

[Hartmut Goebel]

Am 12.02.2017 um 15:37 schrieb David Craven:
> I think that it is a minor
> issue at best, since anything that isn't accessible over the network or running
> with any sort of privileges is not very useful.

I strongly disagree!

Every piece of software available on the system may the intruder. The
server may not be running so it can not be attacked in the first place.
But if an intruder gains (unprivileged) access to the system, he might
be able to start that server software. Then he might use it for
privilege escalation (if the server software is vulnerable), as a
back-channel or for attacking further systems.


> This hypothetical attacker is trying to escalate privileges. I don't
> see how starting an unprivileged process would help with that.

Well, simply by an exploiting a bug in that software. This is a quite
common case :-)

-- 

Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Add murmur.

[pelzflorian (Florian Pelz)]

On 02/12/2017 06:01 PM, Hartmut Goebel wrote:
> Am 12.02.2017 um 15:37 schrieb David Craven:
>> I think that it is a minor
>> issue at best, since anything that isn't accessible over the network or running
>> with any sort of privileges is not very useful.
> 
> I strongly disagree!
> 
> Every piece of software available on the system may the intruder. The
> server may not be running so it can not be attacked in the first place.
> But if an intruder gains (unprivileged) access to the system, he might
> be able to start that server software. Then he might use it for
> privilege escalation (if the server software is vulnerable), as a
> back-channel or for attacking further systems.
> 

An attacker with enough privileges to run Murmur has enough privileges
to install Murmur anyway (perhaps but not necessarily by using Guix). Do
I misunderstand?

Regards,
Florian

Re: Add murmur.

[David Craven]

Hi Hartmut,

Sorry for my snide remark...

>> This hypothetical attacker is trying to escalate privileges. I don't
>> see how starting an unprivileged process would help with that.
>
> Well, simply by an exploiting a bug in that software. This is a quite
> common case :-)

It is my understanding that exploiting a bug in that software can not
help gaining access to privileges that the exploited software does not
have, since this would be a kernel bug.

All attacks that I'm aware of buffer overflow, cross site scripting, sql
injection rely on inserting some code that gets run. But this code
shares the process of the vulnerable program so by extension it shares
it's privileges.

If an attacker already has the privileges required to start the software
I don't think it's possible to gain any more privileges unless that software
has the setuid bit set.

But I have a tendency to oversimplify things, because it gives me the
feeling that I understand it =P

David

Re: server and client in one package -> security issue

[Ludovic Courtès]

Hello,

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 09.02.2017 um 23:50 schrieb Ludovic Courtès:
>> I think the only reason to separate things usually is size, not
>> “aesthetics.”  So I’d be in favor of keeping both in the same output if
>> there’s no size problem.
>
> Separating clients and servers is not an "aesthetic" thing. It's a
> matter of security.
>
> One basic rule for hardening systems is: "only install the required
> software". If we munge server and clients packages, this obeys this rule.
>
> In my day-business I'm a security consultant (CISSP, CSSLP  and ISO
> 27001 Lead Implementer). And from my point of view Guix already has a
> medium problem of acceptance since it munges development-files and
> run-time files into one package - as we do for all libraries. This
> already contradicts the above mentioned basic rule.
>
> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]
>
> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.

Heheh, good for you!  ;-)

Seriously though, all I’m saying is that, until now, the main (only?)
criterion that we had for multiple outputs was size:

  https://www.gnu.org/software/guix/manual/html_node/Packages-with-Multiple-Outputs.html
  https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html (#5)

This patch was using a different criterion.

Now, back to the “only install the required software”, I wouldn’t go as
far as you do.  I generally agree with the rule, but I’m skeptical as to
what this buys you from a security perspective: users can always install
whatever they want by hand anyway, and do you have an idea as to how
much code they install via their browser?

murmurd becomes a problem security-wise when you actually run it and
expose it to the network.  But that’s true of any piece of software that
talks to the network, especially if it’s written in C/C++.

The real solution to that is not to make it harder to install this or
that piece of software IMO.  Rather it’s to make sure they only run when
really needed, and in isolated environments as much as possible, as per
the “principle of least authority” (POLA).

WDYT?

Ludo’.

Re: Add murmur.

[Ludovic Courtès]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On 02/12/2017 06:01 PM, Hartmut Goebel wrote:
>> Am 12.02.2017 um 15:37 schrieb David Craven:
>>> I think that it is a minor
>>> issue at best, since anything that isn't accessible over the network or running
>>> with any sort of privileges is not very useful.
>> 
>> I strongly disagree!
>> 
>> Every piece of software available on the system may the intruder. The
>> server may not be running so it can not be attacked in the first place.
>> But if an intruder gains (unprivileged) access to the system, he might
>> be able to start that server software. Then he might use it for
>> privilege escalation (if the server software is vulnerable), as a
>> back-channel or for attacking further systems.
>> 
>
> An attacker with enough privileges to run Murmur has enough privileges
> to install Murmur anyway (perhaps but not necessarily by using Guix).

Definitely.  And they might just as well run software that’s more useful
for their purposes, like a botnet server.  :-)

Ludo’.

Re: Add murmur.

[ng0]

On 17-02-12 14:37:53, Ludovic Courtès wrote:
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > On 17-02-11 15:31:15, Ludovic Courtès wrote:
> >> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> [...]
> 
> >> > As far as I know right now, it does not have any graphical features or
> >> > dependencies.
> >> >
> >> > mumble:murmur -> total: 1072.6 MiB
> >> > mumble:out    -> total: 1111.2 MiB
> >> 
> >> And what about the total reported by
> >> 
> >>   guix size mumble:murmur mumble:out
> 
> [...]
> 
> > store item                                                       total    self
> > /gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19         1111.2     5.6   0.5%
> > /gnu/store/l4as1725kds2rrpz2l1pcfz8bjn256qd-mumble-1.2.19-murmur  1072.6     1.2   0.1%
> 
> [...]
> 
> > total: 1112.3 MiB
> 
> For 1.2 MiB, I’d say keep both in the same output.
> 
> Could you update the patch accordingly?
> 
> Thank you!
> 
> Ludo’.
> 

I will take the shortcut here and sent the updated patch with just "out"
as output (to the nex guix-patches@ list), but I want to continue
the discussion around client/server
separation as I think it's worth for some outcome. Even if it's just to
document why Guix is safe when everything is combined :)

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: server and client in one package -> security issue (was: Add murmur)

[Danny Milosavljevic]

Hi,

I think the argument that things that don't exist can't be abused is a good one.

However, a regular user can install it anyway. I don't remember when I last ran "guix package -i" as root. I just run it using my regular user account.

So to separate the outputs adds just a miniscule step.

In the end, there's a trade-off to be made. Either we trust users to develop, too, or not. Obviously they can use it for good or bad, then. 

I myself am a free software hacker and I'd prefer if systems automatically had the development stuff installed so others can be free software hackers, too.

And an experienced hacker doesn't need header files either. I made up some of my own just searching Google - it's not difficult and takes about 30 min at most.

If we want hardened critical production systems, I agree it should only contain absolutely required files with programs as simple as one can get them, use SELinux and use hardened gcc and someone should have reviewed the base libraries and any other stuff that runs (basically until a reasonable confidence level is reached).

I don't think Guix should do that, though. IMO locking down everything for users is basically the antithesis of the FSF.

Re: server and client in one package -> security issue (was: Add murmur)

[ng0]

On 17-02-14 10:16:51, Danny Milosavljevic wrote:
> Hi,
> 
> I think the argument that things that don't exist can't be abused is a good one.
> 
> However, a regular user can install it anyway. I don't remember when I last ran "guix package -i" as root. I just run it using my regular user account.
> 
> So to separate the outputs adds just a miniscule step.
> 
> In the end, there's a trade-off to be made. Either we trust users to develop, too, or not. Obviously they can use it for good or bad, then. 
> 
> I myself am a free software hacker and I'd prefer if systems automatically had the development stuff installed so others can be free software hackers, too.
> 
> And an experienced hacker doesn't need header files either. I made up some of my own just searching Google - it's not difficult and takes about 30 min at most.
> 
> If we want hardened critical production systems, I agree it should only contain absolutely required files with programs as simple as one can get them, use SELinux and use hardened gcc and someone should have reviewed the base libraries and any other stuff that runs (basically until a reasonable confidence level is reached).
> 
> I don't think Guix should do that, though. IMO locking down everything for users is basically the antithesis of the FSF.
> 

Interjecting here my opinion for a short moment, I think with hardening
gcc and other parts of the toolchain more can be achieved.
I don't want to be too optimistic, but I hope to be done with one part
of this by summer (doing work in parallel).

Whatever results from this discussion should be written down in the
documentation, as this is obviously an impression and question which
could arise.

What makes my gut feeling (practical experience with hardening is
limited to the SysOps and compiling side with me) okay is that Gentoo
doesn't do much more than some Elf, PaX kernel (at your choice), GrSec
or SELinux, some tools for pax etc, and hardening the libcs.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Add murmur.

[Hartmut Goebel]

Am 12.02.2017 um 18:54 schrieb David Craven:
> If an attacker already has the privileges required to start the software
> I don't think it's possible to gain any more privileges unless that software
> has the setuid bit set.

You are right. I implicitly made some assumptions like setuid bit set.

Nevertheless each additional piece of software already available eases
the attack since less work and less skills are required.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue

[Hartmut Goebel]

Am 13.02.2017 um 15:13 schrieb Ludovic Courtès:
> Now, back to the “only install the required software”, I wouldn’t go as
> far as you do.  I generally agree with the rule, but I’m skeptical as to
> what this buys you from a security perspective: users can always install
> whatever they want by hand anyway, and do you have an idea as to how
> much code they install via their browser?

Looks like we are talking about different systems. I'm talking about
hardened systems, esp. servers, where users are not allowed to install
additional software – not even browser add-on.

Yes, even on these systems a skilled person can install any software
he/she wants. But it is much effort and requires more skills – depending
on a lot of parameters – to bring an exploit to the system as if the
exploit is already there since some software including the exploit is
already installed.

Is stress the example with the door of your flat again: For a skilled
person opening a locked door is easy even if there is a pun tumbler lock
[1]. But would you use just a ward key instead, which can be opened by
nearly anybody – and even lay the skeleton key [2] beside the door?

And this what hardening is about: reducing the attack surface and
removing as many tools as a possible.

Is a GNU/Linux distribution separates components sorrowly, its easier to
harden the system, which makes the distribution more attractive compared
to other distributions.

[1] https://en.wikipedia.org/wiki/Pin_tumbler_lock
[2] https://en.wikipedia.org/wiki/Skeleton_key

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue

[Hartmut Goebel]

Am 14.02.2017 um 10:16 schrieb Danny Milosavljevic:
> I don't think Guix should do that, though. 

I think guix should provide the tools for doing so. Guix has the big
advantage of providing trustworthy packages, but kicks itself out of the
race if hardening is so much complicated.

> IMO locking down everything for users is basically the antithesis of the FSF.

The "user" is the company, the employees work on behalf of the company.
So the software freedom has to be available toe the company not to the
individual employee.

As a company I'm expecting the user to *not* install software on their
computers (not talking about developers here). Otherwise its like
allowing workers to bring their own hammer to the building site or their
own machines into the factory building. If the hammer is inappropriate
and is deforming all nails, or the machine is producing scrap, the
company the the one bear the consequences.


-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue

[Andy Wingo]

On Tue 14 Feb 2017 11:28, Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Am 13.02.2017 um 15:13 schrieb Ludovic Courtès:
>> Now, back to the “only install the required software”, I wouldn’t go as
>> far as you do.  I generally agree with the rule, but I’m skeptical as to
>> what this buys you from a security perspective: users can always install
>> whatever they want by hand anyway, and do you have an idea as to how
>> much code they install via their browser?
>
> Looks like we are talking about different systems. I'm talking about
> hardened systems, esp. servers, where users are not allowed to install
> additional software – not even browser add-on.

If the user has no access to the Guix store and daemon, so they can't
even "guix package --install foo", then you're operating on effectively
a snapshot of the store, right?  So perhaps you want a facility that
when exporting this store snapshot can remove some subset of files, like
for example the include/ tree on all store directories.  But because
this is just an snapshot/export of the store, it doesn't seem necessary
to actually change any particular Guix package to reach your goal, as
far as I understand things anyway.

Andy

Re: server and client in one package -> security issue

[Maxim Cournoyer]

Apologies for digging up a 2 months old message, but I felt compelled to :)

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Am 14.02.2017 um 10:16 schrieb Danny Milosavljevic:
>> I don't think Guix should do that, though. 
>
> I think guix should provide the tools for doing so. Guix has the big
> advantage of providing trustworthy packages, but kicks itself out of the
> race if hardening is so much complicated.
>
>> IMO locking down everything for users is basically the antithesis of the FSF.
>
> The "user" is the company, the employees work on behalf of the company.
> So the software freedom has to be available toe the company not to the
> individual employee.
>

From what I've read and understand, freedom is for any and all
individuals running the software. The employees of your company also
deserve freedom. Freedom doesn't necessarily goes against good
security. I believe Guix and Hurd are steps in the right direction in
achieving freedom of users in a shared/corporate environment.

> As a company I'm expecting the user to *not* install software on their
> computers (not talking about developers here). Otherwise its like
> allowing workers to bring their own hammer to the building site or their
> own machines into the factory building. If the hammer is inappropriate
> and is deforming all nails, or the machine is producing scrap, the
> company the the one bear the consequences.

I believe one of GNU's goal is to bridge (remove the gap between)
developers and users. The system should empower the users to
experiment/study/learn/share the software if they want to and removing
barriers to the tools.

My 2 cents,

Maxim