On 18 Jun 2023, at 21:11, Страхиња Радић wrote:

> On 23/06/18 11:18AM, Stefan Monnier wrote:
>> BTW, why are the public keys available publicly?
>
> You don't seem to understand asymmetric cryptography. Public keys are called
> "public" precisely because they should be shared with the general public. They
> can and should be made available on the Internet publicly. It is one's
> *private* keys which should be kept private.
>

Generally speaking, the existence of a public identifier can be sensitive information.

As an example, while e-mail addresses are usually assumed to be safe to share[1], that isn’t always true. A list of 4500 email adresses belonging to high school students in the Oslo area leaked a while back, and journalists found that a extremist, far-right political party made a significant effort to get this list in an effort to recruit supporters[2].

On 6 May 2022, at 0:11, Michael M wrote:

> When trying to bootstrap Hare, configuring to compile harec fails with an error
> message that the runtime does not support Darwin (macOS). Is there any plans to
> eventually support Darwin?

From the release post (https://harelang.org/blog/2022-04-25-announcing-hare/):

> We also only support Linux and FreeBSD today, and want to do more ports in the
> future. We have no intention of supporting non-free platforms, but because the
> language is standardized, a third-party implementation or fork could easily
> develop Windows or macOS support if desired.

For a short discussion, take a look at https://news.ycombinator.com/item?id=31152020

On 28 Dec 2021, at 12:15, Simon Ser <contact@emersion.fr> wrote:
> I'd rather not:
> 
> - Passing the config params each time hut is invoked is annoying for users. The
>  README should explain how to setup hut for day-to-day use, not for a one-time
>  use.
> - Tokens are like passwords. Passing them as CLI args saves them in the shell
>  history, which isn't very nice.
 
I agree with all the above. I was thinking of a use case such as a CI/CD 
pipeline, but they could probably just store a configuration using their
preferred secrets manager.

> Maybe we could have some kind of `hut auth` command which asks the user to

On 28 Dec 2021, at 02:06, Thorben Günther <admin@xenrox.net> wrote:
> I would move this sentence above the example configuration. Something
> like "Create a configuration file at `~/.config/hut/config` (macOS:
> `~/Library/Application Support/hut/config`" ):

My concern was that placing it above might not be sustainable if many more
platforms are added, hurting readability, and that exceptions to the 
default[1] behaviour could be added below.

Consider:

    Create a configuration file at `~/.config/hut/config`
    (macOS: `~/Library/Application Support/hut/config`;
    Windows `%AppData%/hut/config`; Plan 9: `$home/lib/hut/config`)

Thanks for your feedback.

Would it not make more sense to use config flags > environment > default
behaviour? Using the flags or using environment variables is an explicit
action, while using a default is an implicit action. I would be surprised if
explicitly saying "please use this config file" did not work because the file
I did not want to use exists.

This does also present some challenges, but it seems more consistent with how
other applications behave. (I think?)

> On 28 Dec 2021, at 02:17, Thorben Günther <admin@xenrox.net> wrote:
> 
> On Mon, Dec 27, 2021 at 01:20:28PM +0100, Marcus Pettersen Irgens wrote:

On this topic, would you be in favour of adding support for defining a custom config file location using an environment variable or a --config flag?

Marcus

While quick to fix, I ran into this issue when installing hut on macOS.

This is my first patch on sourcehut, so please forgive me if I've 
submitted this incorrectly.

---
 README.md     | 5 +++--
 doc/hut.1.scd | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 0e6a6f2..967d966 100644
--- a/README.md
+++ b/README.md
[message trimmed]

From: Marcus Pettersen Irgens <m@mrcus.dev>

---
 marcus | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 marcus

diff --git a/marcus b/marcus
new file mode 100644
index 0000000..66cb3d4
--- /dev/null
+++ b/marcus
@@ -0,0 +1 @@
+I have successfully used git send-email!
[message trimmed]

From: Marcus Pettersen Irgens <m@mrcus.dev>

---
 marcus | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 marcus

diff --git a/marcus b/marcus
new file mode 100644
index 0000000..6d0ecfd
--- /dev/null
+++ b/marcus
@@ -0,0 +1 @@
+I'm about to try git send-email
[message trimmed]