- Dillo-dev - lists.mailman3.com

Re: [PATCH] Toolbar zoom control button

by Rodrigo Arias

Hi, On Tue, Aug 06, 2024 at 01:27:38PM +0200, Rodrigo Arias wrote: > Hi, > > On Tue, Aug 06, 2024 at 01:14:26PM +0200, a1ex(a)dismail.de wrote: > > > Thanks!, so far it seems to be working fine. > > > > > > I'll try to get it merged soon. > > > > Just wanted to check if there is anything else that needs to be > > addressed with this patch. If so, please let me know and I will work on > > it. > > I think it is good as-is, I just need to test it for a bit. I'll try to > merge it once I finish with other changes I'm working on. It is queued for > 3.2.0: > > https://github.com/dillo-browser/dillo/issues/235 I'm working on a zoom icon that a bit more similar to the other icons, but I'm having problems to avoid aliasing in the border due to the limitations of XPM with the alpha transparency. I attach two screenshots, one (zoom.png) with the icon background set to the same color of the menu so the alpha is blended properly (but the icon is not transparent). And another one (zoom-alias.png) with the alpha cutoff at half, so alpha values less than 127 are converted to transparent pixels. This one shows some aliasing in the borders, but it works fine if you change the menu color. Not sure if there is a good solution to this problem, other than manually making the aliasing work well with a sharp border. The other icons cleverly avoid this problem by doing rectangular shapes. I'm also considering leaving the save button by default for now, and moving the zoom button to the right, so we preserve the "muscle memory" of users. I need to play a bit more to see how it "feels". Best, Rodrigo.

Aug. 8, 2024

Re: [PATCH] Toolbar zoom control button

by Rodrigo Arias

Hi, On Tue, Aug 06, 2024 at 01:14:26PM +0200, a1ex(a)dismail.de wrote: >> Thanks!, so far it seems to be working fine. >> >> I'll try to get it merged soon. > >Just wanted to check if there is anything else that needs to be >addressed with this patch. If so, please let me know and I will work on >it. I think it is good as-is, I just need to test it for a bit. I'll try to merge it once I finish with other changes I'm working on. It is queued for 3.2.0: https://github.com/dillo-browser/dillo/issues/235 Best, Rodrigo.

Aug. 6, 2024

Re: [PATCH] Toolbar zoom control button

by a1ex＠dismail.de

Hi Rodrigo, On Sun, 14 Jul 2024 20:17:44 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sun, Jul 14, 2024 at 07:02:50PM +0200, a1ex(a)dismail.de wrote: > >Hi list, > > > >Here is an improved version of my previous patch. > > > >The icon is fixed, it's basic but does the job. If someone wants to > >make a prettier one, I'm open to it. > > > >Other improvements as discussed with Rodrigo: > > > >- Middle click resets zoom level > >- There is now a 'show_zoom' preference in dillorc (enabled by > >default) > >- The save button has been disabled by default > >- The zoom button has been moved to the right of the refresh button > > > >Please let me know if you find any issues, and hope you enjoy it :) > > Thanks!, so far it seems to be working fine. > > I'll try to get it merged soon. Just wanted to check if there is anything else that needs to be addressed with this patch. If so, please let me know and I will work on it. Thanks, Alex

Aug. 6, 2024

Re: [PATCH v2] Unveil patch

by Rodrigo Arias

Hi, On Mon, Aug 05, 2024 at 05:42:54PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >On Mon, 5 Aug 2024 15:06:04 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >> I think we could just not allow $HOME to be set as save_dir (or any >> >> directory that contains $HOME, like /home) and refuse to start if >> >> this is the case. > >Sorry, I guess this is the part that confused me: >"(or any directory that contains $HOME, like /home)" > >I agree with it, just not sure how to implement while still allowing a >save_dir like '$HOME/Downloads', or '/home/user/Downloads'. > >Maybe it's a simple thing, but any help would be appreciated! By "contains" I mean that $HOME cannot be inside save_dir: bad: save_dir=/ bad: save_dir=/home bad: save_dir=/home/<theuser> ok: save_dir=/home/<theuser>/foo ok: save_dir=/tmp Here is a very simple check (doesn't handle /../ and other problems): const char *home = dGethomedir(); const char *save = prefs.save_dir; int nsave = strlen(save); int nhome = strlen(home); if (nsave <= nhome) { /* Prevent save_dir="/home" and save_dir=$HOME */ if (strncmp(save, home, nsave) == 0) { MSG("save_dir cannot contain home\n"); exit(1); } } Best, Rodrigo.

Aug. 5, 2024

Re: [PATCH v2] Unveil patch

by a1ex＠dismail.de

Hi Rodrigo, On Mon, 5 Aug 2024 15:06:04 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> I think we could just not allow $HOME to be set as save_dir (or any > >> directory that contains $HOME, like /home) and refuse to start if > >> this is the case. Sorry, I guess this is the part that confused me: "(or any directory that contains $HOME, like /home)" I agree with it, just not sure how to implement while still allowing a save_dir like '$HOME/Downloads', or '/home/user/Downloads'. Maybe it's a simple thing, but any help would be appreciated! > >Not sure I understand what this achieves. So '/home/user' would be > >blocked, but '/home/user/foo' would be allowed? Why not just > >explicitly block access to ~/.ssh with unveil, and then let the user > >do whatever they want after that? > > Yeah, but there may be a lot of other unknown directories we don't > want Dillo to access to (~/.config, ~/.cache, ...). So I think is a > good approach to block all directories in home, except the downloads > one. > > Another attack may involve encrypting ~/Pictures and asking for a > ransom, so we should prevent any access to home that is not required. I think it's unlikely that a user would explicitly choose $HOME as save_dir, but agree that it would be reasonable to take the precaution just in case. Thanks, Alex

Aug. 5, 2024

Re: [PATCH v2] Unveil patch

by Rodrigo Arias

Hi, On Sun, Aug 04, 2024 at 05:14:52PM +0200, a1ex(a)dismail.de wrote: >> If you see your SSH key in the stdout, the unveil() protection alone >> is not enough to mitigate this attack (check that the key exists >> first, I used id_rsa). This would also confirm that unveil() settings >> don't get inherited in forked children. > >I placed that after the last unveil call and made sure I used a valid >key path. Here is the console output: > >game over exploit, fopen failed: No such file or directory >>From what I am seeing, fork() inherits the unveil, and exec() does >>not. Hmm, I guess that makes more sense. I was thinking we could read the preferences only from Dillo, then unveil accordingly, and then all DPIs would already get the unveiled environment. But as you comment, on the exec() the unveil will reset, so we will need to re-read the dillorc file again. I think this is also a good approach in case someone runs the dpid by hand, so it adheres to what dillorc says. >> Maybe for now we can add a simple implementation of the parser just to >> parse the "save_dir" and the new "enable_unveil" (or similar) option, >> like dpid is doing for dpi_dir. > >Ok thanks, I will try to use that as an example and see if I can get >anywhere with it. Thanks! >> I think we could just not allow $HOME to be set as save_dir (or any >> directory that contains $HOME, like /home) and refuse to start if this >> is the case. > >Not sure I understand what this achieves. So '/home/user' would be >blocked, but '/home/user/foo' would be allowed? Why not just explicitly >block access to ~/.ssh with unveil, and then let the user do whatever >they want after that? Yeah, but there may be a lot of other unknown directories we don't want Dillo to access to (~/.config, ~/.cache, ...). So I think is a good approach to block all directories in home, except the downloads one. Another attack may involve encrypting ~/Pictures and asking for a ransom, so we should prevent any access to home that is not required. Best, Rodrigo.

Aug. 5, 2024

Re: Blurry font

by Rodrigo Arias

Hi, (I'll CC Miles as is not subscribed to the list) On Mon, Aug 05, 2024 at 12:42:26PM +0200, a1ex(a)dismail.de wrote: >Hi, > >On Sun, 4 Aug 2024 23:11:24 +0000 >Miles Wirht <milestheperson(a)posteo.net> wrote: > >> Hello! I've been using the dillo browser to open emails, and I've >> noticed that oftentimes fonts will render blurry, or if they don't, >> they'll become blurry upon a mouse click or any other interaction. Is >> thare an antialising option I'm missing, or is this a deeper issue? >> Thank you for your support. > >I haven't seen that issue before. Perhaps it's something configuration >specific on your end, it would be helpful to know what kind of >operating system and desktop environment you are running. Does the >problem ever happen with other programs, or just Dillo? Have you made >any changes in dillorc, like custom fonts or other display settings? Also, which version of Dillo and FLTK are you using? Any chance you have an HTML test page so we can try to reproduce? Best, Rodrigo.

Aug. 5, 2024

Debian package endorsement request

by Rodrigo Arias

Hi all, I've been trying to update the Dillo Debian package from 3.0.5 to the 3.1.1 version of our repository: https://github.com/dillo-browser/dillo As commented on Fediverse by the maintainer of the Debian package, Axel Beckert (in CC), it would help having an endorsement from previous developers, so we can avoid a xz situation due to the change in upstream: https://fosstodon.org/@xtaran@chaos.social/112909239587911469 Here are all the changes among 3.0.5 and 3.1.1, which contain a lot of commits from Sebastian: https://github.com/dillo-browser/dillo/compare/3.0.5...v3.1.1 And here since the last commit from the original mercurial repo: https://github.com/dillo-browser/dillo/compare/c9b817f5bb8ef2060aa36ebb5b08… I'm adding the dillo-dev mailing list, so we can have a public record, in case we have a similar trust problem in the future. Thanks in advance, Rodrigo.

Aug. 5, 2024

Re: Blurry font

by a1ex＠dismail.de

Hi, On Sun, 4 Aug 2024 23:11:24 +0000 Miles Wirht <milestheperson(a)posteo.net> wrote: > Hello! I've been using the dillo browser to open emails, and I've > noticed that oftentimes fonts will render blurry, or if they don't, > they'll become blurry upon a mouse click or any other interaction. Is > thare an antialising option I'm missing, or is this a deeper issue? > Thank you for your support. I haven't seen that issue before. Perhaps it's something configuration specific on your end, it would be helpful to know what kind of operating system and desktop environment you are running. Does the problem ever happen with other programs, or just Dillo? Have you made any changes in dillorc, like custom fonts or other display settings? Regards, Alex

Aug. 5, 2024

Blurry font

by Miles Wirht

Hello! I've been using the dillo browser to open emails, and I've noticed that oftentimes fonts will render blurry, or if they don't, they'll become blurry upon a mouse click or any other interaction. Is thare an antialising option I'm missing, or is this a deeper issue? Thank you for your support.

Aug. 4, 2024