Re: [PATCH v1] git-send-email-reply: Append subject

["Σταύρος Ντέντος" <stdedos@gmail.com>]

With regards,
Ntentos Stavros


On Sat, 27 Mar 2021 at 11:54, Eric Wong <e@80x24.org> wrote:
> > I thought you said you deployed it :/
>
> Oops :x  I finished the deploy, now :>

Yeah, I saw it a bit later :-p :-D

> > Would it make sense for you to "symlink" /meta/ to /public-inbox/?
> > (as it is for git.git --> /git/)
>
> Not really, since the address is meta@public-inbox.org.
> "public-inbox" is already a long name, and
> "public-inbox.org/public-inbox" is kinda annoyingly long.
>
> (and I've been preferring <80x24.org|yhbt.net>/public-inbox.git
>  for the git repo).

Remember that a symlink (or a 30x redirect) does not cost you anything :-p
It _is_ longer, and it doesn't cost you anything, for the sake of
"finding where is something where you look for it to be" ;-)

> It's been a few years since I checked, but I seem to recall
> there being an option in the web UI of Gmail.

It does, and it is a bit hidden, and a bit global-ish: If you send
e-mails at night ...

> Everything I've read about Docker sounds scary when people are
> grabbing binaries and code from random distributors and just
> running it blindly.  IMHO it encourages dangerous behavior.

Pulling solely from "sane-ish sources" (buster from Debian and your
code from your repo),
should it be okay. The risks (as stated above) should ...

> Having duplicates of things like libc or even Perl is total
> overkill here and not remotely lightweight in my book.
>
> I don't expect anybody to trust me enough to run public-inbox
> without reading it (which is why there'll never be JavaScript).
>
> We only distribute source so people can always read what they're
> running.  We even use a language that makes binary distribution
> (nearly) impossible.

... be outweighed by benefits (clean add and remove, single-ish
up-and-running command).
Of course, you are right of claiming that anywhere, anything can be
inserted - and the more
you pull, the more things you expose yourself to.

https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/

> I would never introduce any soft or hard dependency into a
> project without being knowledgeable and comfortable about it,
> first; and that can take a LOT of time and lead me down rabbit
> holes...

Yeah, me too :-D
Having a more clean deploy&isolation&remove process would facilitate
in me testing more
and providing a cleaner patchset to you.

You might have fixed my patchset yourself (thanks!) but not everyone
is willing to spend time on it.
On the other hand, I am not willing to "pollute" my system with
something tying itself more or less to my system.
(It's not the pollution that I am afraid of, but the sanitization afterwards).
I've barely used chroots, and I am not comfortable using them (because
they require sudo).

Not to say that I am "that comfortable" using docker either! However,
they have created a group which,
if I add myself on it, it (hopefully) uses only the minimal set of
required privileges to do, whatever it is that it does,
without requiring me to type "sudo" (which, I keep telling to myself
that it is "something dangerous" overall).

If you have some tl;dr knowledge on how to make (s)chroots to work
cleanly without any sudo
(after I review a specific subset of rights & get myself access to
e.g. `/var/chroots/*` directory),
I am all ears!

A lot of compiled deb packages use that one way or another, and (mistakenly?)
I feel more comfortable installing via `apt-get install package.deb`
than `make install`.