~lanodan

BZH

https://hacktivis.me/

Haelwenn (lanodan) Monnier

~lanodan/public-inbox

Last active 3 months ago
View more

Recent activity

Re: [PATCH himitsu] himitsu::query: Add error message about duplicate keys 30 days ago

From Haelwenn (lanodan) Monnier to ~sircmpwn/himitsu-devel

[2024-01-22 15:01:55+0100] Armin Preiml:
> query::parse_items should not have the side-effect of writing error
> messages to stdout. It does not fail silently since it returns the
> dupkeys error.

Yeah but that's ignored by secstore/secstore.ha:331 and dupkeys is just !void
so doesn't contains enough information to be useful.

> I think figuring out what keys are duplicates can easily be done by the
> user. Though if this is really a desired feature, the output should be
> done at the tool that uses query::parse. The tool must then figure out
> the duplicates on their own, but then a method to find duplicates could
> be provided by the query module.

[PATCH himitsu] himitsu::query: Add error message about duplicate keys 30 days ago

From to ~sircmpwn/himitsu-devel

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

Otherwise it would silently abort.
---
 himitsu/query/parse.ha | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/himitsu/query/parse.ha b/himitsu/query/parse.ha
index e9c2722..a44cba8 100644
--- a/himitsu/query/parse.ha
+++ b/himitsu/query/parse.ha
@@ -122,6 +122,18 @@ export fn parse_items(items: []str) (query | error) = {
	let prev = keys[0];
	for (let i = 1z; i < len(keys); i += 1) {
[message trimmed]

Re: [RFC v1] Versioned 0.XX.Y releases for Hare 2 months ago

From Haelwenn (lanodan) Monnier to ~sircmpwn/hare-rfc

[2023-12-07 21:42:45-0500] Sebastian:
>On Thu Dec 7, 2023 at 4:29 AM EST, Drew DeVault wrote:
>> I propose that we begin tagging Hare 0.XX.Y versions, for the purpose
>> of improving the relative stability of the ecosystem while Hare begins
>> to be adopted for serious work.
>>
>> The versioning scheme will be a simple date-based scheme for quarterly
>> releases. For instance, if a release were tagged for Q4 2023 (i.e. right
>> now), it would be version 0.23.3, and would be followed by 0.24.0.
>>
>> If this proposal is accepted, the first release would be 0.24.0.
>
>As much as I agree versioned releases would be useful, I think we should
>hold off for a little bit longer. There's quite a few relatively large

Re: [RFC v1] Versioned 0.XX.Y releases for Hare 2 months ago

From Haelwenn (lanodan) Monnier to ~sircmpwn/hare-rfc

[2023-12-07 10:29:02+0100] Drew DeVault:
> 			 STANDARD LIBRARY IMPLICATIONS
> 
> Breaking API changes will have to be recorded and summarized in the
> release notes each quarter. I propose adopting a convention for commit
> messages (to be documented in docs/release.md) wherein a commit which
> makes a breaking change will summarize that change for the release notes
> and be tagged with the special trailer:
> 
> 	Breaking-change: 0.XX.Y
> 
> Where 0.XX.Y is the next version to be released. When preparing the
> release notes, we will gather up all Breaking-change commits written
> between releases and put them in the release notes, which will be

Re: Why I need 'sysctl kernel.unprivileged_userns_clone=1' to my linux in order to run badwolf? 4 months ago

From Haelwenn (lanodan) Monnier to ~lanodan/public-inbox

[2023-10-08 19:33:52+0000] Xavier B.:
>As [StackExchange](https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do) explains it could enable several vulnerabilities.
>
>Can you modify the code in order to run without enable it? Can bwrap run without suid-root?

The annoying thing is as far as I know without the ability to have namespaces created by users means the inability to properly sandbox webkit's web-processes, so instead of having "maybe they can excape the sandbox" it would effectively be "there is no sandbox".

And in my opinion the right thing the Debian patch should have done isn't a toggle via sysctl but via fcaps (like how CAP_SYS_CHROOT is a thing), which would allow to specifically have bwrap able to use user-namespaces without the worse thing of becoming suid-root or in practice having to disable Debian's "security" patch.

Re: Why I need 'sysctl kernel.unprivileged_userns_clone=1' to my linux in order to run badwolf? 4 months ago

From Haelwenn (lanodan) Monnier to ~lanodan/public-inbox

[2023-10-08 14:26:14+0000] Xavier B.:
> Just a librewolf user with desire to migrate to badwolf. But I wonder why I have to set
> 'sysctl kernel.unprivileged_userns_clone=1'
> 
> Any security explanations here?

Yeah, this is required for the sandbox based on bubblewrap when the bwrap executable isn't suid-root.

Probably should check with your distro if this is expected as I would see it as an integration bug.

Best regards

[PATCH hare v2] hare/build: Print arguments of failed command 4 months ago

From Haelwenn (lanodan) Monnier to ~sircmpwn/hare-dev

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

---
 cmd/hare/build/queue.ha | 13 ++++++++++---
 cmd/hare/build/types.ha |  1 +
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/cmd/hare/build/queue.ha b/cmd/hare/build/queue.ha
index 973f9350..82731164 100644
--- a/cmd/hare/build/queue.ha
+++ b/cmd/hare/build/queue.ha
@@ -125,7 +125,6 @@ fn run_task(ctx: *context, jobs: *[]job, t: *task) (bool | error) = {
	io::trunc(lock, 0)?;

[message trimmed]

[PATCH hare] hare/build: Print arguments of failed command 4 months ago

From Haelwenn (lanodan) Monnier to ~sircmpwn/hare-dev

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

---
 cmd/hare/build/queue.ha | 8 ++++++--
 cmd/hare/build/types.ha | 1 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/cmd/hare/build/queue.ha b/cmd/hare/build/queue.ha
index 973f9350..51309459 100644
--- a/cmd/hare/build/queue.ha
+++ b/cmd/hare/build/queue.ha
@@ -175,10 +175,12 @@ fn run_task(ctx: *context, jobs: *[]job, t: *task) (bool | error) = {
	defer io::close(output)!;
	exec::addfile(&cmd, os::stdout_file, output);
[message trimmed]

[PATCH hare-json] Update for hare as of 20230813 5 months ago

From to ~sircmpwn/hare-dev

From: "Haelwenn (lanodan) Monnier" <contact@hacktivis.me>

---
 encoding/json/+test/lexer.ha | 5 +++--
 encoding/json/+test/load.ha  | 2 +-
 encoding/json/lex.ha         | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/encoding/json/+test/lexer.ha b/encoding/json/+test/lexer.ha
index 499d315..019e64c 100644
--- a/encoding/json/+test/lexer.ha
+++ b/encoding/json/+test/lexer.ha
@@ -1,4 +1,4 @@
use bufio;
[message trimmed]

Re: [PATCH hare v2] replace copyright headers with license headers 5 months ago

From Haelwenn (lanodan) Monnier to ~sircmpwn/hare-dev

[2023-09-15 03:07:55+0000] Ember Sawady:
>On Fri Sep 15, 2023 at 2:16 AM UTC, Haelwenn (lanodan) Monnier wrote:
>> - I think there should still be a form of authorship, specially given that both are copyleft and MPL-2.0 makes it likely to be vendored/reused elsewhere, people typically fail at adding authorship when doing so (and you'd end up with different author lines in third-party software).
>>    For example:
>>
>>      Copyright 2019 Hare Authors <https://harelang.org>
>
>dislike having the year here, could do something like
>
>// License: MPL-2.0
>// (c) Hare authors <https://harelang.org>
>
>modelled after what we currently do