Re: LibreWolf 130.0-1 notes

2024-09-07 Thread André Batista 
Hi Ian,

sex 06 set 2024 às 08:29:40 (1725622180), i...@retrospec.tv enviou:
> 130.0-1 is out, but there’s an issue around DNS-over-HTTP preferences
> changing[1] in this version.  Since this has a negative impact on users
> requiring them to reset their preferences to correct, I’m skipping this one
> and will package the next release.
> 
> I separately have an issue open with them around the Firefox 130 AI Chatbot
> integration.  This uses non-free "AI" services which have been trained on
> stolen GPL code, and hopefully will get stripped out of LW.  It’s an
> experimental opt-in feature at the moment, but shouldn’t be present at all.
> 
> Once there’s a fix for #1975, I’ll work on packaging it, disabling the AI
> nonsense in the Guix package definition, if necessary.
> 
> Thanks,
> 
>  — Ian
> 
> [1]: https://codeberg.org/librewolf/issues/issues/1975

In my opinion we should keep these discussions open and transparent for
the whole guix community, unless there are some serious concerns in
sharing it with the internet at large or if they are truly personal
exchanges of no interest to other guix.

Since I believe your above message _is_ of interest to guix (guixen
could have a different understanding on this heated debate and could
have a distinct judgement on the desirability of skipping this release),
there is no personal or private information on your message and since
we were instructed to keep team discussions on guix-devel[1], I'm
taking the liberty to CC the list here.

As for the content of your message, I think it's your take here, but IMO
the DoH bug is annoying but not a show stopper, unless of course they
are about to release a fixed version (which seems to be the case).

As for the 'non-free AI services', well aren't services beyond
free/non-free or always non-free since they run on machines beyond users'
control? I did not read on it though and would certainly be in favor of
removing it if it means that librewolf would be auto-connecting to some
services upon start or if it has code that is collecting /analyzing
users' input, suggesting services or etc.

Finally, though I see why some people are concerned with corporations
training models on GPL'd code without attribution and without warning
their users of the need to respect GPL when further sharing, I'd
suggest you to avoid loaded terms such as 'stolen'[2]. License or 
copyright infringement should not be equated with theft, copyright
should not be equated with private property. IMO it goes against the
very core idea of free software to equate those things.

1. https://lists.gnu.org/archive/html/guix-devel/2024-08/msg00174.html
2. https://www.gnu.org/philosophy/words-to-avoid.html#Theft

Re: Merging ‘core-updates’ real soon

2024-08-29 Thread André Batista 
Hi,

qua 28 ago 2024 às 18:56:45 (1724882205), kaelyn.al...@protonmail.com enviou:
> > 
> > Thoughts?
> 
> Do you have any modifications to e.g. the binutils package definition? It 
> looks like the error is coming from using "cons" to append a configure flag; 
> from the output above:

Not local, no.

> #:configure-flags (cons "--enable-64-bit-bfd" # ("LDFLAGS=-static-libgcc" "--enable-new-dtags" 
> "--with-lib-path=/no-ld-lib-path" "--enable-install-libbfd" 
> "--enable-deterministic-archives" "--enable-64-bit-bfd" 
> "--enable-compressed-debug-sections=all" "--enable-lto" 
> "--enable-separate-code" "--enable-threads")) gnu/packages/base.scm:661:28 
> a765d108>)
> 
> I'd encountered a similar error in the past after more packages were migrated 
> to use gexps because I hadn't yet learned of the gexp-aware helpers like 
> "substitute-keyword-arguments". Basically the configure flags need to be 
> extended using gexp operations instead of basic list operations like "cons". 
> An example can be seen in the definition of "binutils-boot0" in 
> gnu/packages/commencement.scm:
> 
> (substitute-keyword-arguments (package-arguments binutils)
>   ((#:configure-flags cf)
>#~(append (list #$(string-append "--target="
> (boot-triplet))
>"--disable-gprofng") ;requires Bison
>  #$cf)

But your comment put me on the right track and it seems both grub and
ipxe-qemu use inherited binutils' definitions which were trying to set
configure-flags using simple list procedures. I've sent a patch fixing
that on #72882, but I guess that patch can wait and be merged on master
right after core-updates?

Cheers,

[Browser-Team] Re: Request for assistance maintaining LibreWolf

2024-08-29 Thread André Batista 
Hi Ian, browser-team, guix,

qui 29 ago 2024 às 07:30:39 (1724927439), m...@tobias.gr enviou:
> Hullo Ian,
> 
> On 28 August 2024 23:15:23 UTC, Ian Eure  wrote:
> >Ludovic Courtès  writes:
> >> I would suggest not creating a separate mailing list per team.  […]
> >How does one request the creation of a browser-team mailing list?
> 
> We'd ask the GNU sysadmins, but I agree with Ludo' here.
> 

So as to not trow the baby with the bath water, how about a subject
prefix to $team_name as in this current?

This way one can easily filter for that tag and redirect it to a higher
priority box or organize its archive localy and at the same time warn
subscribers that current message does not expect greater attention from
uninterested people on the list (all being equally welcome to comment,
of course).

I'm not very sure that this is needed as this list is not that busy, but
wouldn't mind it as well.

Re: Merging ‘core-updates’ real soon

2024-08-28 Thread André Batista 
Hi again,

ter 27 ago 2024 às 16:04:43 (1724785483), nan...@riseup.net enviou:
> 
> PS: my i686 system reconfigure is still ongoing right now. I'll report
> back if any other issue comes around (fingers crossed).
> 

Unfortunately, I've had no luck. System reconfiguration fails when trying
to build 'binutils-64-bit-bfd-2.41' with a more cryptic error message:

$ zcat 
/var/log/guix/drvs/01/yl5wdsb4v16l7dphvr37090qmr7li8-binutils-64-bit-bfd-2.41.drv.gz
ice-9/read.scm:126:4: In procedure read-expr*:
/gnu/store/34j6xzczp0291qvrggzcfqnbqks1djz1-binutils-64-bit-bfd-2.41-builder:1:2744:
 Unknown # object: "#<"

This builder has only one occurrence of '#<' which is a '#':

$ cat 
/gnu/store/34j6xzczp0291qvrggzcfqnbqks1djz1-binutils-64-bit-bfd-2.41-builder
(begin (use-modules (guix build gnu-build-system) (guix build utils)) (begin 
(define %build-inputs (quote (("source" . 
"/gnu/store/gfw3m9f9jz1m36f1sz1vqnqvfrqsb2k1-binutils-2.41.tar.zst") ("bison" . 
"/gnu/store/jng0ydhr8xw28svcgm1dzbykli29wxih-bison-3.8.2") ("tar" . 
"/gnu/store/m8h0hv6g549nh9n9xfjphjrzqg8g2r2w-tar-1.34") ("gzip" . 
"/gnu/store/b3mdz7n6j9dzkyi0scdbldnzrwcc3nlg-gzip-1.13") ("bzip2" . 
"/gnu/store/2aqa6wi5y81yprflz59cjk91pgwvy48w-bzip2-1.0.8") ("file" . 
"/gnu/store/k4ycd4b9zqrzxmdivjbhakjjymg8bfsv-file-5.45") ("diffutils" . 
"/gnu/store/ra6mdl923hpjw0yyrrj3j1snhibs32z0-diffutils-3.10") ("patch" . 
"/gnu/store/p76jj9sv007cj4hmfskjjsscy9z0vrc6-patch-2.7.6") ("findutils" . 
"/gnu/store/p1g6q2qnp1m0iza4d09mknyqx1xspws3-findutils-4.9.0") ("gawk" . 
"/gnu/store/mbgs4jl3vbhi6vya4p64hjfyj3739qzi-gawk-5.3.0") ("zstd" . 
"/gnu/store/542d6rh6ci06ngcgiprnambqfws09i4f-zstd-1.5.2") ("sed" . 
"/gnu/store/mqb37w640rg4hx9nx00274r2kz54kc3w-sed-4.8") ("grep" . 
"/gnu/store/wpykxc5blf6vcw7bmqa4k21sqs44p8as-grep-3.11") ("xz" . 
"/gnu/store/cnv0rzdrdmlb3c43sr9n5vagjh3qn0k1-xz-5.4.5") ("coreutils" . 
"/gnu/store/yxcrwcdd7blcczlc50i6lgcnj2w7nlja-coreutils-9.1") ("make" . 
"/gnu/store/c6i7ihy40368732m574lpgvygikd4ql9-make-4.4.1") ("bash" . 
"/gnu/store/ak41ci13apcxh5ahd8lc9rv6l7bqnwym-bash-minimal-5.1.16") 
("ld-wrapper" . "/gnu/store/d7ayy457nq3a42myfgqs2mc2zbx7z406-ld-wrapper-0") 
("binutils" . "/gnu/store/zf310q29z3apmkp3g6hck29z1d39ajly-binutils-2.41") 
("gcc" . "/gnu/store/xgqbv2lkh6z9x6wgyfjvcpr8paw0zd9a-gcc-11.4.0") ("libc" . 
"/gnu/store/g88kcslhrdmd0b5bap2f2ghj26i7jdlm-glibc-2.39") ("libc:static" . 
"/gnu/store/3wg51p14zipq2rl2k59pw7i8hirbdnb5-glibc-2.39-static") ("m4" . 
"/gnu/store/xam8sj9hdr7y0rgqv138xvlbxrqp348f-m4-1.4.19") ("kernel-headers" . 
"/gnu/store/hpcf3359y90qb3c8c1x5syr0ivrj54bg-linux-libre-headers-5.15.49" 
(define %outputs (list (cons "out" ((@ (guile) getenv) "out" (define 
%output (assoc-ref %outputs "out")) (gnu-build #:source 
"/gnu/store/gfw3m9f9jz1m36f1sz1vqnqvfrqsb2k1-binutils-2.41.tar.zst" #:system 
"i686-linux" #:build "i686-unknown-linux-gnu" #:outputs %outputs #:inputs 
%build-inputs #:search-paths (quote (("BASH_LOADABLES_PATH" ("lib/bash") ":" 
directory #f) ("C_INCLUDE_PATH" ("include") ":" directory #f) 
("CPLUS_INCLUDE_PATH" ("include/c++" "include") ":" directory #f) 
("OBJC_INCLUDE_PATH" ("include") ":" directory #f) ("OBJCPLUS_INCLUDE_PATH" 
("include/c++" "include") ":" directory #f) ("LIBRARY_PATH" ("lib" "lib64") ":" 
directory #f) ("GUIX_LOCPATH" ("lib/locale") ":" directory #f) ("TZDIR" 
("share/zoneinfo") #f directory #f))) #:phases %standard-phases #:locale 
"C.UTF-8" #:separate-from-pid1? #t #:bootstrap-scripts %bootstrap-scripts 
#:configure-flags (cons "--enable-64-bit-bfd" #) #:make-flags (quote ("MAKEINFO=true")) #:out-of-source? #t #:tests? 
#t #:test-target "check" #:parallel-build? #t #:parallel-tests? #t 
#:patch-shebangs? #t #:license-file-regexp 
"^(COPYING.*|LICEN[CS]E.*|[Ll]icen[cs]e.*|Copy[Rr]ight(\\.(txt|md))?)$" 
#:strip-binaries? #t #:validate-runpath? #t #:make-dynamic-linker-cache? #t 
#:license-file-regexp 
"^(COPYING.*|LICEN[CS]E.*|[Ll]icen[cs]e.*|Copy[Rr]ight(\\.(txt|md))?)$" 
#:strip-flags (quote ("--strip-unneeded" "--enable-deterministic-archives")) 
#:strip-directories (quote ("lib" "lib64" "libexec" "bin" "sbin")

Thoughts?

Cheers,

Re: Merging ‘core-updates’ real soon

2024-08-27 Thread André Batista 
Hi guix,

seg 26 ago 2024 às 11:33:56 (1724682836), nan...@riseup.net enviou:
> 
> However, when running tests it fails the checkasm_audiodsp test with
> the following error:
> 
> checkasm: using random seed 3387428695
> SSE:
>  - audiodsp.audiodsp [OK]
> SSE2:
>  - audiodsp.audiodsp [OK]
> SSSE3:
>audiodsp.vector_clip_int32_ssse3 (audiodsp.c:112)
>  - audiodsp.audiodsp [FAILED]
> checkasm: 1 of 4 tests have failed
> threads=1
> 
> This _could_ be a hardware error here, but line 112 of audiodsp.c is
> also doing some pointer comparison and, well it's doing some audio
> vector thingy so afaik it could also be related.
> 
> So what I'm tending to now is to create a separate openal-for-ffmpeg
> package definition, patching its CMakeLists.txt at line 350 whe it
> tries to check if gcc has protected or default visibility support,
> remove that setting and conditionaly enable this alternate package
> when building on i686.
> 
> Does that make sense?

No this does not make much sense. Openal is not included on that
specific test and it links fine, it's the test per se that failed. So it
was probably a hardware error after all. Offloading the build to another
machine succeded after applying the patch on #72838 which I've sent for
your appreciation.

Cheers,

PS: my i686 system reconfigure is still ongoing right now. I'll report
back if any other issue comes around (fingers crossed).

Re: Merging ‘core-updates’ real soon

2024-08-26 Thread André Batista 
Hi Andreas,

qui 22 ago 2024 às 11:50:56 (1724338256), andr...@enge.fr enviou:
> Am Wed, Aug 21, 2024 at 10:43:05PM +0200 schrieb Ludovic Courtès:
> > To me, that’s the last blocker, even though there’s room for improvement
> > here and there (for instance, FFmpeg currently fails to build on
> > i686-linux).
> 
> Just so that others do not have to repeat my check: ffmpeg fails to find
> openal in the configure phase for i686:
> ld: /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.o: in function 
> `check_alGetError':
> test.c:(.text+0x1): undefined reference to `alGetError'
> collect2: error: ld returned 1 exit status
> check_lib openal AL/al.h alGetError -lopenal
> check_func_headers AL/al.h alGetError -lopenal
> test_ld cc -lopenal
> test_cc
> BEGIN /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c
> 1   #include 
> 2   #include 
> 3   long check_alGetError(void) { return (long) alGetError; }
> 4   int main(void) { int ret = 0;
> 5ret |= ((intptr_t)check_alGetError) & 0x;
> 6   return ret; }
> END /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c
> 

This is not the whole story.

ffmpeg's configure script tries different library search paths
incantations and this error refers to when it tries with no
command line arguments.

On some other tries it actually finds openal and alGetError, but then
it aborts with the following linking error:

ld: /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.fLOeyoSu/test.o: non-canonical 
reference to canonical protected function `alGetError' in 
/gnu/store/j4qdsqxb95yllkby0w2dx6d9lib24zmn-openal-1.23.1/lib/libopenal.so
ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

Searching for it, it seems this was previously a runtime error, that
now fails at compile time[1] and is due to the pointer type cast
when referencing alGetError on line 5 above and the segmented memory
model of x86.

Notice that this code snippet is run for all libraries and on the ones
I've checked that have no issues linking the protection is default:

$ LANG=C readelf -a 
/gnu/store/3b65jkdm5ip7j9j0xarzpp8iyqfgq0m7-x265-3.5/lib/libx265.so.199 | grep 
x265_api_get
   827: 0009d500   322 FUNCGLOBAL DEFAULT   12 x265_api_get_199

or

$ LANG=C readelf -a 
/gnu/store/8f9irjzk1zcg8z97p4zw239hnqn0plqk-xvid-1.3.7/lib/libxvidcore.so.4.3 | 
grep xvid_global
33: 00015790  4010 FUNCGLOBAL DEFAULT   12 xvid_global

while on openal it is 'protected':

$ LANG=C readelf -a 
/gnu/store/j4qdsqxb95yllkby0w2dx6d9lib24zmn-openal-1.23.1/lib/libopenal.so.1.23.1
 | grep alGetErro
000fd45c  f001 R_386_32  00026a80   alGetError
   240: 00026a80   246 FUNCGLOBAL PROTECTED   12 alGetError

Since, however, pointer equality is not needed as the above code only
tries to check if it can get a non null pointer to the given function
and the code is not meant to be run, I believe it would be safe in this
case to bypass this safety check[2] and force configure to succeed
(we already now that openal was found).

So I've bypassed this check here by adding a 'true' clause and then it
configures and builds fine.

However, when running tests it fails the checkasm_audiodsp test with
the following error:

checkasm: using random seed 3387428695
SSE:
 - audiodsp.audiodsp [OK]
SSE2:
 - audiodsp.audiodsp [OK]
SSSE3:
   audiodsp.vector_clip_int32_ssse3 (audiodsp.c:112)
 - audiodsp.audiodsp [FAILED]
checkasm: 1 of 4 tests have failed
threads=1

This _could_ be a hardware error here, but line 112 of audiodsp.c is
also doing some pointer comparison and, well it's doing some audio
vector thingy so afaik it could also be related.

So what I'm tending to now is to create a separate openal-for-ffmpeg
package definition, patching its CMakeLists.txt at line 350 whe it
tries to check if gcc has protected or default visibility support,
remove that setting and conditionaly enable this alternate package
when building on i686.

Does that make sense?

I'll try that and report back if no one shows a better solution[3].

Cheers,

1. https://sourceware.org/bugzilla/show_bug.cgi?id=28875
2. https://sourceware.org/bugzilla/show_bug.cgi?id=29512
3. AKA, is there a similar simple and effetive test for dynamic
symbols that does not rely on pointer references?

Re: Request for assistance maintaining LibreWolf

2024-08-22 Thread André Batista 
Hi Ludo, Ian, guixen,

qua 21 ago 2024 às 22:54:31 (1724291671), l...@gnu.org enviou:
> 
> > Ian Eure  writes:
> >
> >>>
> >>> I believe the usual way of doing something like this is via teams (see
> >>> ./etc/teams.scm ).
> >>>
> >>
> >> I’m not sure whether/how well this mechanism works for non-committers.
> >
> > I believe it should.  AFAIK pretty much all it does is to automatically
> > add the team members onto CC list when running `git send-email'.
> 
> Yes, it works whether or not one has commit rights, and I agree that it
> could be helpful here.

Should I send a patch adding myself to the team? What is expected from
team members?

> > At the same time it is not really meant as a general notification
> > system, so usefulness for you depends on whether some committer will
> > merge the commit adding librewolf team (with you in it).
> 
> Ian, what about teaming up with other Firefox derivative maintainers?
> I’m thinking notably of André and Clément who’ve worked on Tor Browser
> on Mullvad Browser, Mark H Weaver who’s been maintaining IceCat, and
> perhaps Jonathan who’s been taking care of IceDove (Cc’d)?
> 
> Of course, each of these package is different but they’re in the same
> area so it probably makes sense to share reviewing efforts here.

I was reticent on this mainly because (i) I have never actually used
LibreWolf and I don't have a clear picture of it besides it being a
"Firefox + Arkenfox - Mozilla Branding" [1](?); (ii) I expect that most
of these security (aka urgent) patches will land on the same day on a
regular basis for all 4 browsers and given Mullvad and TorBrowser
sources will be late in the game, I'll probably not be able to do such
a timely (yet again, urgent) review, which could add to Ian's
frustration, instead of relieving it; and (iii) AFAIUI, LibreWolf moves
at a faster pace, which adds to my concern of not being able to keep up
in the long run.

That being said, given those patches have remained unreviewed for weeks
in a row, I guess I can at least help improve the current situation and
give commiters some more confidence that a given patch will not break
hell loose when commited and so I'm willing to help with these reviews.
However, I cannot promise to maintain it if/when Ian's lead happens to
go missing.

One question in that regard: is there any difference between reviewing
through QA's web interface and sending mail commands to debbugs'
control? Is any of them preferable? I'd rather use the mail interface if
that's enough.

Cheers.

1. No disrespect meant to the project or its users, just my own
current cluelessness exposed. I'll read the docs on it to understand
it better though.


signature.asc
Description: PGP signature

Re: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

2024-07-30 Thread André Batista 
Hi!

seg 29 jul 2024 às 14:33:59 (1722274439), rek...@elephly.net enviou:
> Efraim Flashner  writes:
> 
> > On Fri, Jul 26, 2024 at 02:51:49PM -0400, Leo Famulari wrote:
> >> For a long time we've not been able to build linux-libre on i686-linux
> >> because the source unpacking process runs out of memory.
> >
> > I believe if we limit the unpacking process to not more than 8 cores we
> > can avoid that problem.
> >
> >> I'm forwarding this bug to guix-devel to get more attention.
> >> 
> >> Is anybody actually using i686-linux anymore? Or should we begin to
> >> officially remove support for it?
> >
> > Keeping this to i686-linux specifically, what generation of hardware
> > supports i686 but not x86_64? Some (very) quick checking on wikipedia
> > suggests that the x60 from 2006 was either 32-bit or 64-bit, and I
> > believe there was an atom chip from 2015 that was 32-bit. Specifically,
> > that makes the newest hardware (at least from the CPU perspective) 10
> > years old at least.
> 
> FWIW, I'm using one of those Atom chips in a netbook for an installation
> of Sugar Desktop.  I upgrade it every few months or so.  If I'm the only
> user of i686-linux I would not want to condemn the project to supporting
> the architecture for my sake.

For the record, I'm another one still using those atom netbooks. Most
software that I use on that machine still builds and runs fine, with the
occasional hiccup.

But even though I use the arch, I also don't feel particularly inclined
to fix the occasional errors and can understand if people here decide to
drop support to it.

Re: [PATCH] gnu: torbrowser: Update to 13.0.15 [security fixes].

2024-05-31 Thread André Batista 
Hi Clément,

qui 30 mai 2024 às 12:07:58 (1717081678), clem...@lassieur.org enviou:
> Hi André,
> 
> I'm currently struggling against a cancer, so it's hard for me to work.  I 
> hope to be better in a few months.  Meanwhile I'll do my best but I'll be 
> slow to react and work.

I'm terribly sorry for you and I do hope you can find the inner strenght
and will to fight it and beat it. I also hope you are well supported
during this hard times.

> I've updated torbrowser and mullvadbrowser but I'm not able to understand how 
> to fix "unknown introductory commit and signer" at the moment.  So I can't 
> push them, they are attached.  I tested my updates.  Please if someone can 
> push them that would be great.

I'll review and test you mullvadbrowser patch and open a new issue in
your place then.

I'll also try to keep this browsers up to date on a more timely manner
whilst you take time to cure yourself. So as to not disturb or pressure
you any longer, I won't be Cc'ing you any longer.

Take care

Re: [PATCH] doc: cookbook: Update entry about getting substitutes through Tor.

2020-07-03 Thread André Batista 
Hi Brice,

dom 28 jun 2020 às 11:37:32 (1593355052), br...@waegenei.re enviou:
> Hello André,
>
> I tought I already had applied your patch, but I forgot to do it.
> It's now applied as f8945734a5abff69644284231cc47fb67456657b, sorry
> for the delay.

No big deal, thanks for your initiative.

> I would love to know when you manage to advance on that front.

It's currently beyond my understanding, but hopefully not for long.

Cheers!

Re: [PATCH] Add Tor client only package definition

2020-07-03 Thread André Batista 
Hi Ludo,

qui 02 jul 2020 às 11:36:24 (1593700584), l...@gnu.org enviou:
> Hi André,
> 
> Applied, but without those evil tabs that ‘guix lint’ reported.  ;-)

That's embarrassing. I could swear I had removed those before sending.

> The closure as reported by ‘guix size’ is 96.7 MiB for ‘tor-client’
> vs. 97.0 MiB for ‘tor’.  So it’s not compelling from that point of view,
> but having less “dead” code when you only use the client is a probably
> good idea.
> 
> Thanks!

I'm glad to have helped and hope to be able to contribute more.
Tonight it's celebration time for me, I'll be drinking to the memory
of those who came before and made it possible for me to be here now.

:D

> PS: In the future, please email guix-patc...@gnu.org to minimize chances
> of losing sight of the patch:
> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

Sure thing. I've only sent it here because I was unsure if it was
worth it.

Thank you for all your work on guix!

Re: [PATCH] doc: cookbook: Update entry about getting substitutes through Tor.

2020-06-18 Thread André Batista 
Hello Brice,

qua 17 jun 2020 às 08:37:59 (1592393879), br...@waegenei.re enviou:
> Hello André,
> 
> Thank you for the patch and your feedback!

It's me who should be thanking you!

> When writing this section of the cookbook I was worried that some
> readers will misunderstood it so I added a big warning at the
> front but it doesn't seems to be enough since you sent this mail.

Sorry to disturb you, your warning was clear enough. I've only
thought that there was room for improvement whilst there remains
the need for a proper solution to the problem at hand.

> I would like to keep the warnings at the beginning of the section
> to be sure that readers don't miss it when skimming trough it.
> Any rewording of that part to make the scope of the section or
> the warnings more clear is welcome.

It follows attached a new version of the previous patch which
changes the comment to the warning quote. I had previously thought
that it would be worse to inflate the warning with this comment even
more so as the section's title already mentions it's related to
substitutes.

> Note that this section is only about getting *substitutes* through
> tor and it should probably be kept that way to avoid confusing the
> user in regard to what (narrow) security benefit this configuration
> offer.

Note taken, but it seems to me that if someone is going through the
trouble of configuring guix to get substitutes through Tor, such a
person would most likely also wish to update guix through the same
network. It does nothing to fix the possible leaks when substitutes
aren't available, but it makes it clear that it's possible/advisable
on such scenario to pull using torsocks. I don't think it misinforms
users.

> On a wider front I would prefer to have a foolproof configuration
> that route *all* guix related traffic through Tor, instead of that
> half-way setup.  Providing a way to 'torify' any service with
> something like 'make-forkexec-constructor/trosocks', as
> 'make-forkexec-constructor/container' does for containerizing a
> service, would be great[0].  A less engaged option would be to
> make 'guix-daemon' compatible with 'torsocks' since doing it so
> makes guix unusable[1].

I too would prefer it, but a half-way setup is what we have for now.
So a three-quarters-way would be an improvement though not the fix
we're in need. I'll dig deeper and will come back to you if I make
any progress.
From 1d6e29dcbc5b9a8659294af033863a31526eab76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Batista?= 
Date: Thu, 18 Jun 2020 10:23:23 -0300
Subject: [PATCH] doc: cookbook: Update entry about getting substitutes through
 Tor.
To: guix-devel@gnu.org

* doc/guix-cookbook.texi (Getting substitutes from Tor): Update
section warning to mention the use of torsocks when pulling.
---
 doc/guix-cookbook.texi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/guix-cookbook.texi b/doc/guix-cookbook.texi
index 1342826c97..d5a8459363 100644
--- a/doc/guix-cookbook.texi
+++ b/doc/guix-cookbook.texi
@@ -15,6 +15,7 @@ Copyright @copyright{} 2020 Oleg Pykhalov@*
 Copyright @copyright{} 2020 Matthew Brooks@*
 Copyright @copyright{} 2020 Marcin Karpezo@*
 Copyright @copyright{} 2020 Brice Waegeneire@*
+Copyright @copyright{} 2020 André Batista@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -1799,10 +1800,16 @@ HTTP/HTTPS will get proxied; FTP, Git protocol, SSH, 
etc connections
 will still go through the clearnet.  Again, this configuration isn't
 foolproof some of your traffic won't get routed by Tor at all.  Use it
 at your own risk.
+
+Also note that the procedure described here applies only to package
+substitution. When you update your guix distribution with
+@command{guix pull}, you still need to use @command{torsocks} if
+you want to route the connection to guix's git repository servers
+through Tor.
 @end quotation
 
 Guix's substitute server is available as a Onion service, if you want
-to use it to get your substitutes from Tor configure your system as
+to use it to get your substitutes through Tor configure your system as
 follow:
 
 @lisp
-- 
2.26.2



signature.asc
Description: PGP signature

Re: [bug#41694] [PATCH] doc: cookbook: Add entry about getting substitutes through Tor.

2020-06-16 Thread André Batista 
Hello Brice,

I think it would be useful to warn users that when pulling there is
a direct connection to guix git repos, so to route it through Tor,
one needs to use torsocks. It wont make the configuration foolproof,
but it will reduce the leaks to clearnet.

From 6a73b1b1129d3d636d7a0559dffa19e5d40aaf0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Batista?= 
Date: Tue, 16 Jun 2020 23:13:03 -0300
Subject: [PATCH] doc: cookbook: Add info on the need of using torsocks when
 pulling.
To: guix-devel@gnu.org

* doc/guix-cookbook.texi (Getting substitutes from Tor): Add note at
  the end on using torsocks when pulling.
---
 doc/guix-cookbook.texi | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/guix-cookbook.texi b/doc/guix-cookbook.texi
index 1342826c97..1852ce6c3a 100644
--- a/doc/guix-cookbook.texi
+++ b/doc/guix-cookbook.texi
@@ -15,6 +15,7 @@ Copyright @copyright{} 2020 Oleg Pykhalov@*
 Copyright @copyright{} 2020 Matthew Brooks@*
 Copyright @copyright{} 2020 Marcin Karpezo@*
 Copyright @copyright{} 2020 Brice Waegeneire@*
+Copyright @copyright{} 2020 André Batista@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -1802,7 +1803,7 @@ at your own risk.
 @end quotation
 
 Guix's substitute server is available as a Onion service, if you want
-to use it to get your substitutes from Tor configure your system as
+to use it to get your substitutes through Tor configure your system as
 follow:
 
 @lisp
@@ -1843,6 +1844,11 @@ sudo herd set-http-proxy guix-daemon 
http://localhost:9250
 guix build --substitute-urls=https://bp7o7ckwlewr4slm.onion …
 @end example
 
+Note that the procedure described above applies only to package substitution.
+When you update your guix distribution with @command{guix pull}, you should
+use @command{torsocks} if you want to route the connection to guix git
+repository servers through Tor.
+
 @c *
 @node Advanced package management
 @chapter Advanced package management
-- 
2.26.2



signature.asc
Description: PGP signature

Re: [PATCH] Add Tor client only package definition

2020-06-16 Thread André Batista 

From ac47ba538dd5cf628b26cce05e3b15b24ca03077 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Batista?= 
Date: Tue, 16 Jun 2020 19:20:57 -0300
Subject: [PATCH] gnu: Add tor-client.
To: guix-devel@gnu.org

* gnu/packages/tor.scm (tor-client): New variable.
---
 gnu/packages/tor.scm | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/tor.scm b/gnu/packages/tor.scm
index 2f2623b0e6..06debfed07 100644
--- a/gnu/packages/tor.scm
+++ b/gnu/packages/tor.scm
@@ -8,6 +8,7 @@
 ;;; Copyright © 2017 Rutger Helling 
 ;;; Copyright © 2018 Ricardo Wurmus 
 ;;; Copyright © 2020 Vincent Legoll 
+;;; Copyright © 2020 André Batista 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -27,6 +28,7 @@
 (define-module (gnu packages tor)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
+  #:use-module (guix utils)
   #:use-module (guix download)
   #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
@@ -85,11 +87,36 @@ location.  Tor works with many of your existing 
applications, including
 web browsers, instant messaging clients, remote login, and other
 applications based on the TCP protocol.
 
+This package is the full featured @code{tor} which is needed for running
+relays, bridges or directory authorities. If you just want to access the Tor
+network or to setup an onion service you may install @code{tor-client}
+instead.")
+(license license:bsd-3)))
+
+(define-public tor-client
+  (package
+   (inherit tor)
+   (name "tor-client")
+   (arguments
+(substitute-keyword-arguments (package-arguments tor)
+ ((#:configure-flags flags)
+  (append flags
+  '("--disable-module-relay")
+   (synopsis "Client to the anonymous Tor network")
+   (description
+"Tor protects you by bouncing your communications around a distributed
+network of relays run by volunteers all around the world: it prevents
+somebody watching your Internet connection from learning what sites you
+visit, and it prevents the sites you visit from learning your physical
+location.  Tor works with many of your existing applications, including
+web browsers, instant messaging clients, remote login, and other
+applications based on the TCP protocol.
+
 To @code{torify} applications (to take measures to ensure that an application,
 which has not been designed for use with Tor such as ssh, will use only Tor for
 internet connectivity, and also ensures that there are no leaks from DNS, UDP 
or
-the application layer) you need to install @code{torsocks}.")
-(license license:bsd-3)))
+the application layer) you need to install @code{torsocks}.  This package only
+provides a client to the Tor Network.")))
 
 (define-public torsocks
   (package
-- 
2.26.2



signature.asc
Description: PGP signature

Re: [PATCH] Add Tor client only package definition

2020-05-31 Thread André Batista 
Hi Ludo,

ter 26 mai 2020 às 11:56:21 (1590504981), nan...@riseup.net enviou:
> dom 24 mai 2020 às 22:51:16 (1590371476), l...@gnu.org enviou:
> > It looks good to me overall!  Some nitpicking:
> >
> > We’d rather use ‘substitute-keyword-arguments’ to augment
> > #:configure-flags without touching the other keyword arguments (there
> > are several examples in the source).
> > 
> >
> > We generally avoid concatenating text like this, for the reasons
> > explained at:
> > 
> >   https://guix.gnu.org/manual/en/html_node/Synopses-and-Descriptions.html
> > 
> >
> > Regarding the format of patches, you can take a look at this:
> > 
> >   https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
> 
> I'll send a new patch taking your warnings into account.

I'm a little bit short on time, so I couldn't do everything I was supposed
to. I'm sending the attached patch for your consideration, just in case
someone wants to try it out, though I still need to clone the git repo, try
to build it on a pre-inst-env, and try to compile on archs other than i686
and x86_64.

I've run './etc/indent-code.el', guix lint and there where no errors.

It might take me some time to properly set up everything here and complete
the remaining steps, so please do tell me if you think the reasoning on the
previous email does not hold up or is not worth the trouble.

This diff was taken upon commit 018cffc9c9e5a5855733f5f45a1c4d396bb6a321.
--- a/gnu/packages/tor.scm  2020-05-31 00:45:08.246476629 -0300
+++ b/gnu/packages/tor.scm  2020-05-31 16:36:57.355970253 -0300
@@ -27,6 +27,7 @@
 (define-module (gnu packages tor)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
+  #:use-module (guix utils)
   #:use-module (guix download)
   #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
@@ -85,11 +86,36 @@
 web browsers, instant messaging clients, remote login, and other
 applications based on the TCP protocol.
 
+This package is the full featured @code{tor} which is needed for running
+relays, bridges or directory authorities. If you just want to access the Tor
+Network or to setup an onion service you may install @code{tor-client}
+instead.")
+(license license:bsd-3)))
+
+(define-public tor-client
+  (package
+(inherit tor)
+(name "tor-client")
+(arguments
+ (substitute-keyword-arguments (package-arguments tor)
+   ((#:configure-flags flags)
+`(list ,@(cdr flags)
+  "--disable-module-relay"
+(synopsis "Client to the anonymous Tor network")
+(description
+ "Tor protects you by bouncing your communications around a distributed
+network of relays run by volunteers all around the world: it prevents
+somebody watching your Internet connection from learning what sites you
+visit, and it prevents the sites you visit from learning your physical
+location.  Tor works with many of your existing applications, including
+web browsers, instant messaging clients, remote login, and other
+applications based on the TCP protocol.
+
 To @code{torify} applications (to take measures to ensure that an application,
 which has not been designed for use with Tor such as ssh, will use only Tor for
 internet connectivity, and also ensures that there are no leaks from DNS, UDP 
or
-the application layer) you need to install @code{torsocks}.")
-(license license:bsd-3)))
+the application layer) you need to install @code{torsocks}.  This package only
+provides a client to the Tor Network.")))
 
 (define-public torsocks
   (package


signature.asc
Description: PGP signature