user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: "Σταύρος Ντέντος" <stdedos@gmail.com>
To: meta@public-inbox.org
Cc: Eric Wong <e@80x24.org>
Subject: Re: [PATCH v1] git-send-email-reply: Append subject
Date: Sat, 27 Mar 2021 16:01:50 +0200	[thread overview]
Message-ID: <CAHMHMxUEZiWoqGmz4i6aSceGzf=7CZ7u7JJu89=XUFva+9-3Rg@mail.gmail.com> (raw)
In-Reply-To: <20210327095431.GA32057@dcvr>

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`.

  reply	other threads:[~2021-03-27 14:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 16:31 Stavros Ntentos
2021-03-26 19:36 ` Eric Wong
     [not found]   ` <CAHMHMxVS4tVvUYvWUmk8L8oqPPxtYW-MF_57Vwuzug-asWQiQg@mail.gmail.com>
2021-03-26 21:35     ` Eric Wong
2021-03-27  8:39       ` Stavros Ntentos
2021-03-27  9:54         ` Eric Wong
2021-03-27 14:01           ` Σταύρος Ντέντος [this message]
2021-03-27 19:32             ` Eric Wong
2021-03-28 16:00               ` Σταύρος Ντέντος
2021-03-28 22:58                 ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHMHMxUEZiWoqGmz4i6aSceGzf=7CZ7u7JJu89=XUFva+9-3Rg@mail.gmail.com' \
    --to=stdedos@gmail.com \
    --cc=e@80x24.org \
    --cc=meta@public-inbox.org \
    --subject='Re: [PATCH v1] git-send-email-reply: Append subject' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/public-inbox.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).