Re: Add murmur.
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.goe...@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)
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: server and client in one package -> security issue (was: Add murmur)
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: Add murmur.
On 17-02-12 14:37:53, Ludovic Courtès wrote: > ng0 skribis: > > > On 17-02-11 15:31:15, Ludovic Courtès wrote: > >> ng0 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: .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 .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: Add murmur.
"pelzflorian (Florian Pelz)" 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.
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: Add murmur.
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.
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.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Add murmur.
> 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: Add murmur.
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.
> 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.
On 17-02-12 14:37:53, Ludovic Courtès wrote: > ng0 skribis: > > > On 17-02-11 15:31:15, Ludovic Courtès wrote: > >> ng0 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: .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 .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.
ng0 skribis: > On 17-02-11 15:31:15, Ludovic Courtès wrote: >> ng0 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: .2 MiB >> >> And what about the total reported by >> >> guix size mumble:murmur mumble:out [...] > store item totalself > /gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19 .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: server and client in one package -> security issue (was: Add murmur)
> 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: server and client in one package -> security issue (was: Add murmur)
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.goe...@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/
server and client in one package -> security issue (was: Add murmur)
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.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Add murmur.
On 17-02-11 15:31:15, Ludovic Courtès wrote: > ng0 skribis: > > > On 17-02-10 22:54:21, Marius Bakke wrote: > >> ng0 writes: > >> > >> > On 17-02-09 23:50:02, Ludovic Courtès wrote: > >> >> ng0 skribis: > >> >> > >> >> > On 17-02-09 17:50:04, Ludovic Courtès wrote: > >> >> >> Hi ng0! > >> >> >> > >> >> >> contact@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: .2 MiB > > And what about the total reported by > > guix size mumble:murmur mumble:out store item totalself /gnu/store/1zdk5x87ig5zvqcn5f8lllnmrywg9asa-mumble-1.2.19 .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.3227.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.0142.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.2114.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.2976.0 2.6 0.2% /gnu/store/vzlgcmkys1dpw238wq7qb9klb4g84p5l-kmod-23 75.2 0.3 0.0% /gnu/store/hin7b7nq2jizd93089zzmjh7i4781j8
Re: Add murmur.
ng0 skribis: > On 17-02-10 22:54:21, Marius Bakke wrote: >> ng0 writes: >> >> > On 17-02-09 23:50:02, Ludovic Courtès wrote: >> >> ng0 skribis: >> >> >> >> > On 17-02-09 17:50:04, Ludovic Courtès wrote: >> >> >> Hi ng0! >> >> >> >> >> >> contact@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: .2 MiB And what about the total reported by guix size mumble:murmur mumble:out ? Ludo’.
Re: Add murmur.
On 17-02-10 22:54:21, Marius Bakke wrote: > ng0 writes: > > > On 17-02-09 23:50:02, Ludovic Courtès wrote: > >> ng0 skribis: > >> > >> > On 17-02-09 17:50:04, Ludovic Courtès wrote: > >> >> Hi ng0! > >> >> > >> >> contact@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: .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.
ng0 writes: > On 17-02-09 23:50:02, Ludovic Courtès wrote: >> ng0 skribis: >> >> > On 17-02-09 17:50:04, Ludovic Courtès wrote: >> >> Hi ng0! >> >> >> >> contact@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. signature.asc Description: PGP signature
Re: Add murmur.
On 17-02-09 23:50:02, Ludovic Courtès wrote: > ng0 skribis: > > > On 17-02-09 17:50:04, Ludovic Courtès wrote: > >> Hi ng0! > >> > >> contact@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.
ng0 skribis: > On 17-02-09 17:50:04, Ludovic Courtès wrote: >> Hi ng0! >> >> contact@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.
On 17-02-09 17:50:04, Ludovic Courtès wrote: > Hi ng0! > > contact@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.
Hi ng0! contact@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.
contact@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/
[PATCH] gnu: mumble: Add 'murmur' output.
From: ng0
* 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
;;; Copyright © 2016 Lukas Gradl
;;; Copyright © 2016 Francesco Frassinelli
-;;; Copyright © 2016 ng0
+;;; Copyright © 2016, 2017 ng0
;;;
;;; 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
Add murmur.
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 2/3] gnu: Add murmur-hash.
* gnu/packages/textutils.scm (murmur-hash): New variable. --- gnu/packages/textutils.scm | 39 +++ 1 file changed, 39 insertions(+) diff --git a/gnu/packages/textutils.scm b/gnu/packages/textutils.scm index ebcf4b9..ce83c4d 100644 --- a/gnu/packages/textutils.scm +++ b/gnu/packages/textutils.scm @@ -373,3 +373,42 @@ runs Word\".") (description "UTF8-CPP is a C++ library for handling UTF-8 encoded text in a portable way.") (license license:boost1.0))) + +(define-public murmur-hash + ;; There are no releases so package directly from a git commit. + (let ((commit "61a0530f28277f2e850bfc39600ce61d02b518de")) +(package + (name "murmur-hash") + (version (string-append "0-1." (string-take commit 7))) + (source (origin +(method git-fetch) +(uri (git-reference + (url "https://github.com/aappleby/smhasher.git";) + (commit commit))) +(file-name (string-append name "-" version ".tar.gz")) +(sha256 + (base32 + "1hasigzz5dyx8dzf1arzwahhph2p4vnsq32wlyh99nga2z4hd8si" + (build-system gnu-build-system) + (arguments + `(#:phases + (modify-phases %standard-phases + (delete 'configure) + (delete 'build) + (delete 'check) + (replace 'install + (lambda* (#:key outputs #:allow-other-keys) + (with-directory-excursion "src" + (let ((out (string-append + (assoc-ref outputs "out") + "/include"))) + (install-file "MurmurHash3.cpp" out) + (install-file "MurmurHash3.h" out))) + #t) + (home-page "https://github.com/aappleby/smhasher";) + (synopsis "Non-cryptographic hash function for lookup") + (description + "MurmurHash is a non-cryptographic hash function suitable for general +hash-based lookup. The name comes from two basic operations, multiply (MU) +and rotate (R), used in its inner loop.") + (license license:public-domain -- 2.7.4
