Re: Feedback on a new simple firewall service OFF TOPIC PRAISE
Solene Rapenne writes: > Hello, > > I'm looking for advices and feedback. I wrote a simple service (reusing > the iptables service as a start) that I called "firewall", the purpose maybe eventually it could use nftables, which is the better newer version. > is to block all incoming ports and list the ports you want to allow. > The point is to allow users to easily manage their firewall without > knowing about to use iptables. Most of the time opening a few ports and > blocking everything is enough. YES! SWEET, ICY COLD, HOLY ALASKAN ASPARAGUS TIPS! THIS IS AWESOME! How cool is it to abstract away the details for a firewall!? Man I've tried learning iptables, and it is just very weird syntax and hard to understand! Thanks for working on this! I invite you to forward your original email to guix-patc...@gnu.org. That way you open a specific issue and your code is assigned a bug number! -- Joshua Branson (joshuaBPMan in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar
Is Guix vulnerable to this polkit CVE?
Guix commit 9178566954cc7f34d2d991d31df4565adad93508 ought to fix this with a patch and graft. If you haven't updated already, consider doing so. If you want to play with polkit, you can always roll back :P
Re: Is Guix vulnerable to this polkit CVE?
jbra...@dismail.de 写道： You all awesome devs have probably already fixed it, but I am just emailing to make sure. It was fixed in Guix[0], but thank you for your vigilance! o7 Rest well, T G-R [0]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9178566954cc7f34d2d991d31df4565adad93508 signature.asc Description: PGP signature
Is Guix vulnerable to this polkit CVE?
I just found this article on polkit having a CVE: https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/ (https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/) It looks pretty nasty... " The vulnerability enables an unprivileged local user to get a root shell on the system. It’s easy to exploit with a few standard command line tools, as you can see in this short video (https://youtu.be/QZhz64yEd0g). In this blog post, I’ll explain how the exploit works and show you where the bug was in the source code. " In the hacker news comments it is fixed in: https://news.ycombinator.com/item?id=27462247 (https://news.ycombinator.com/item?id=27462247) Polkit version 0.119 fixes it, here's the diff: https://gitlab.freedesktop.org/polkit/polkit/-/commit/a04d13... (https://gitlab.freedesktop.org/polkit/polkit/-/commit/a04d13affe0fa53ff618e07aa8f57f4c0e3b9b81) You all awesome devs have probably already fixed it, but I am just emailing to make sure. Thanks! Joshua "Aim for stars...because even if you'll fall at least you'll fall on Uranus."
Re: [PATCH RFC 0/4] Getting rid of input labels?
Hello!
Ludovic Courtès skribis:
> Here’s a proposal for a soft revolution: getting rid of input labels
> in package definitions. Instead of writing:
>
> (native-inputs
> `(("autoconf" ,autoconf)
>("automake" ,automake)
>("pkg-config" ,pkg-config)
>("guile" ,guile-3.0)))
>
> one can write:
>
> (native-inputs (list autoconf automake pkg-config guile-3.0))
I’m still looking into the feasibility of this change. For it to work,
I think it’s better if the transition to the new style is as fast as
possible. The attached script helps with that: it automatically
converts the source of packages where the conversion does not even
change the package derivation. It generates diffs like this:
@@ -280,10 +280,9 @@ during long operations.")
(base32 "106akalywfmnypzkdrhgz4n4740a8xayspybsw59kq06vz8i2qrc"
(build-system python-build-system)
(native-inputs
- `(("python-mock" ,python-mock)
- ("python-pytest" ,python-pytest)))
+ (list python-mock python-pytest))
(propagated-inputs
- `(("python-nltk" ,python-nltk-3.4)))
+ (list python-nltk-3.4))
(home-page
"https://github.com/yeraydiazdiaz/lunr.py;)
(synopsis "Full-text search library")
@@ -314,13 +313,13 @@ that best match text queries.")
(substitute* "setup.py"
(("==") ">=")))
(propagated-inputs
- `(("python-click" ,python-click)
- ("python-jinja2" ,python-jinja2)
- ("python-livereload" ,python-livereload)
- ("python-lunr" ,python-lunr)
- ("python-markdown" ,python-markdown)
- ("python-pyyaml" ,python-pyyaml)
- ("python-tornado" ,python-tornado)))
+ (list python-click
+ python-jinja2
+ python-livereload
+ python-lunr
+ python-markdown
+ python-pyyaml
+ python-tornado))
(home-page "https://www.mkdocs.org;)
(synopsis "Project documentation with Markdown")
(description "MkDocs is a static site generator geared towards building
You can run the script to modify, say, all the ‘python*’ packages:
./pre-inst-env guile simplify-package-inputs.scm \
$(./pre-inst-env guix package -A '^python' | cut -f1,2 |tr '\t' '@')
It runs in a minute and the resulting diff looks like this:
100 files changed, 4423 insertions(+), 5180 deletions(-)
The script warns when it fails to convert a package or when a comment
could not be preserved during conversion (it tries to preserve margin
comments but it’s a bit of a hack since neither ‘read’ nor
‘pretty-print’ help with that):
--8<---cut here---start->8---
gnu/packages/wxwidgets.scm:318:5: warning: python2-wxpython: input label
'wxwidgets' does not match package name, bailing out
gnu/packages/wxwidgets.scm:315:5: warning: python2-wxpython: margin comment
will be lost
gnu/packages/web.scm:6503:7: warning: python2-clf: non-trivial input, bailing
out
gnu/packages/web.scm:6503:7: warning: python-clf: non-trivial input, bailing out
gnu/packages/tryton.scm:594:5: warning: python-trytond-party: input label
'python-stnum' does not match package name, bailing out
gnu/packages/tls.scm:612:5: warning: python-acme: margin comment will be lost
gnu/packages/time.scm:435:5: warning: python-arrow: margin comment will be lost
gnu/packages/sphinx.scm:133:21: warning: python2-sphinx: computed input list,
bailing out
--8<---cut here---end--->8---
I don’t have hard figures but I think the majority of packages are
handled, which means we could do a big switch at once, or in a short
amount of time (so we can review removed comments and fix them up).
We could then forcefully convert some of the remaining cases, with the
understanding that the derivation would be different but presumably
valid; finally, there’d be the more complex cases that need to be
manually dealt with.
Thoughts?
Thanks,
Ludo’.
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2021 Ludovic Courtès
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix. If not, see
Re: "guix pull" expiry channels
Hi Pierre, On Wed, 09 Jun 2021 at 21:26, Pierre Neidhardt wrote: > Same here, I've experienced this bug multiple times for a few months > already. Thanks for confirming. What is your frequency for pulling? More or less? Cheers, simon
Re: RISCV porting effort
On Wed, Jun 09, 2021 at 12:28:22AM +0200, Gabriel Wicki wrote: > Hello everyone! > > > Efraim Flashner skribis: > > > Porting Guix comes with two parts: building the bootstrap-tarballs and > > > adding support for the new architecture in (gnu packages bootstrap). > > > Support for riscv was added to GCC with 7.1.0 so I had to bump the > > > bootstrap GCC to 7 (and adjust some inputs), and guile-2.0.14 didn't > > > known the endianness of riscv64 so instead of patching it I bumped the > > > bootstrap guile to 3.0. I uploaded my bootstrap-tarballs to my regular > > > spot after signing them and switched over to the riscv machine. > > Do i understand correctly that the bootstrap-tarballs can be > cross-compiled and tested (to some extent) in a qemu-system-riscv? Or does > this *have* to fail (by Guix's design) due to it not being bootstrappable? > They get cross compiled from another architecture, using the package definitions in gnu/packages/make-bootstrap.scm. From what I've seen online, it should be possible to boot Ubuntu's riscv64 image using qemu. I haven't tried enabling riscv64 support in my binfmt service and try building on my main machine. > > On Tue, Jun 08, 2021 at 03:43:44PM +0200, Ludovic Courtès wrote: > > If the HiFive works fine, let me remind you that we have budget to buy > > hardware, so we could just as well order a couple of these right away > > (maybe you’ll have Guix System running by the time we receive them ;-)). > > > > What we need is someone to order the machine(s) and to host it > > afterwards, with stable connectivity. This must be agreed upon by the > > Spending Committee (currently Tobias, Ricardo, and myself; email > > guix-fina...@gnu.org). You’ll then be reimbursed by the FSF, our > > current fiscal sponsor. > > > > Any takers? Or should we wait until you have more experience with > > yours, Efraim? > I could see myself doing that. I've been thinking about getting a HiFive > Unmatched for a while and getting the hardware makes working on it a bit > more exciting! > > Do i understand correctly that this machine would then be used to > build Guix packages and serve them? I.e. a worker on ci.guix.gnu.org? > > > Have a nice week! > gabriel > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: RISCV porting effort
On Tue, Jun 08, 2021 at 03:43:44PM +0200, Ludovic Courtès wrote: > Hello! > > Efraim Flashner skribis: > > > Porting Guix comes with two parts: building the bootstrap-tarballs and > > adding support for the new architecture in (gnu packages bootstrap). > > Support for riscv was added to GCC with 7.1.0 so I had to bump the > > bootstrap GCC to 7 (and adjust some inputs), and guile-2.0.14 didn't > > known the endianness of riscv64 so instead of patching it I bumped the > > bootstrap guile to 3.0. I uploaded my bootstrap-tarballs to my regular > > spot after signing them and switched over to the riscv machine. > > > > Building Guix from sources is much easier thanks to the work of Vagrant, > > I was able to apt install most of the dependencies on riscv. The > > packaged version of guile-zlib was too old in 21.04 so I built that from > > source (0.1.0 is available in Debian experimental), and I also had to > > build gnutls from source for the guile-3.0 bindings. I added the riscv > > binaries to (gnu packages bootstrap) and temporarily switched the > > raw-build function to look for 3.0 guile libraries instead of 2.0. > > > > Where I'm at right now: > > Downloading using the daemon (builtin:download) fails currently, it says > > it doesn't have permissions to open-file to write downloaded files to > > the store. > > I haven't built anything using the bootstrap binaries to see if they > > actually work yet. > > Exciting news! I saw discussions about this ‘guix perform-download’ > issue on IRC. Did you eventually find what the problem is? Right now it seems to be some sort of permissions error with writing to the store. I haven't been able to figure out what's causing it yet. > If the HiFive works fine, let me remind you that we have budget to buy > hardware, so we could just as well order a couple of these right away > (maybe you’ll have Guix System running by the time we receive them ;-)). On one hand they seem similar to some of our aarch64 boards (but with 16GB of RAM), on the other hand it'd be a coup to announce serious support for the platform so quickly. > What we need is someone to order the machine(s) and to host it > afterwards, with stable connectivity. This must be agreed upon by the > Spending Committee (currently Tobias, Ricardo, and myself; email > guix-fina...@gnu.org). You’ll then be reimbursed by the FSF, our > current fiscal sponsor. > > Any takers? Or should we wait until you have more experience with > yours, Efraim? > > Thanks, > Ludo’. > I had to pay import tax when I received mine, and I assume those in Europe did too, so I'd recommend they be hosted in the US since IIRC they're shipping from Texas. It might be nice to wait until we have it working for sure, but the lead time is still expected to be 6 months between ordering and shipping dates. I suppose if something else comes along that's faster we could always cancel an order and switch to that. I have mine sitting in a mini-ITX case, using a libre-respecting NVIDIA card. Definitely a more serious board than the aarch64 boards I've bought in the past. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: "guix pull" expiry channels
Once every second week maybe? Depends, if I need an urgent upgrade then it might be more. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
