~lanodan

BZH

https://hacktivis.me/

Haelwenn (lanodan) Monnier

~lanodan/public-inbox

Last active 6 months ago
View more

Recent activity

Re: [PATCH] replace asm keyword 10 days ago

From Haelwenn (lanodan) Monnier to ~mpu/qbe

Nice!  Nearly sent a similar patch to fix compilation with tcc,
so not just a clang thing.

Re: Handling of collisions in unique-id a month ago

From Haelwenn (lanodan) Monnier to ~bitfehler/m2dir

[2024-04-18 14:18:33+0200] Knut Magnus Aasrud:
>> One thing that strikes me as very weird though is the unique-id,
>> not only it's way too short 2^12 = 4096, I think it's reasonable
>> to expect more emails than this.
>
>The hash is 12 bytes, not bits. 2^(8*12)≈8e28 which should be big enough.

Erf, reminds me of why I tend to stick to octet.

And yeah 12 bytes should be enough.

Handling of collisions in unique-id a month ago

From Haelwenn (lanodan) Monnier to ~bitfehler/m2dir

Hi,

Thanks for m2dir I think it solves the issues I have with Maildir as well.

One thing that strikes me as very weird though is the unique-id,
not only it's way too short 2^12 = 4096, I think it's reasonable
to expect more emails than this.

And the collision solving method makes it unsuitable to non-centralised
usage, including folder manipulation done by the email client
itself or moving emails around locally (as the unique-id mustn't
conflict in .meta).

I think something like an UUID using time+random would make the most

regression: hangs when a display is too short 2 months ago

From Haelwenn (lanodan) Monnier to ~adnano/wmenu-devel

How-to-reproduce:
- fullscreen terminal with similar font (ie. foot -f monospace)
- python -c "print('a'*$COLUMNS)" | wmenu

Got:
- wmenu works fine when items are short enough
- wmenu eats a full CPU core and RAM until OOM-Killed when an item is too long

For context this breaks my himitsu prompt on a FullHD vertical monitor where:
- COLUMNS=180 in `foot -f monospace`
- hiq | cut -b 1-60 | wmenu → works
- hiq | cut -b 1-70 | wmenu → hangs
- hiq | wc -l ⇒ 326
- longest item: 111 characters

Re: [PATCH himitsu] himitsu::query: Add error message about duplicate keys 4 months 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 4 months 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 5 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 5 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? 7 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? 7 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