Items tagged: ⭐️ (60)

Ajuste StateRegistration para validar caso o número total de dígitos informado  seja menor que o numero esperado.

support default scheme customization

This allows the user to specify a scheme that should be used to try to open a bookmark if the bookmark is missing a scheme. E.g. `www.example.com` will be changed to `http://www.example.com` or `https://www.example.com` automatically before an open/browse is attempted.

Originally this patch simply forced opening with https, but it has since been modified to default to either http or https, at the user's preference. The default scheme will continue to be http, for now.

Forcing https by default was a suggestion based mainly on my own use case. I have 3,678 bookmarks. 3,670 use https and 7 use http. Of those 7, at least a couple are dead links and a couple are http-only to prove a point.

I keep "https only" on in my daily driver browser (Firefox) and my alternate browser (Chromium). I can still view http sites if I click through the warning.

I did a few lazyweb searches and found a presentation from the 26th USENIX in 2017:

  https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/felt

In the video on that page they cover how https is more often available, used, and even defaulted to for many websites, somewhere around 50-90% depending on how you measure it and where you get your data (and this is back in 2017).

That presentation is about a paper by Felt et al titled "Measuring HTTPS Adoption on the Web":

  https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-felt.pdf

One of their data sources is MAWI, so I just peeked at MAWI's latest charts:

  https://mawi.wide.ad.jp/mawi/samplepoint-F/2025/202510241400.html

I did some super simple math. I can't say if this is at all valid, but I just compared the first two numbers where I saw http and https and found http is 14.4% of the total and https is 85.6%. Looks like I was comparing ip.tcp.http packets vs. ip.tcp.https packets. So that's something there to look at, I guess.

(83894509 ip https packets + 14072651 ip http packets ) = 97967160 total packets

14072651 ÷ 97967160 = 0.144 = 14.4% http packets

83894509 ÷ 97967160 = 0.856 = 85.6% https packets

MAWI data snippet:

```
Protocol Breakdown

     protocol		packets			bytes		bytes/pkt
------------------------------------------------------------------------
 total        334771299 (100.00%)     364013578524 (100.00%)   1087.35
 ip           288108851 ( 86.06%)     307918329080 ( 84.59%)   1068.76
  tcp         125995157 ( 37.64%)     190503802981 ( 52.33%)   1511.99
   http        14072651 (  4.20%)      24776980541 (  6.81%)   1760.65
   https       83894509 ( 25.06%)     150210613012 ( 41.27%)   1790.47
...✂️...
```

Anyway, sorry for all this noise, it's really just breadcrumbs in case someone wants to do actual research.

Also I'm really enjoying buku so far. Thank you for sharing it!

Unit tests pass locally.

No part of this commit log message was AI-generated.

---

add --default-scheme to manpage

---

pass default_scheme into browse() as a keyword arg

feat: update cities

DIR: don't display invalid data with devices

When doing `DIR NUL` findfirst will actually return success
with an attribute indicating a device exists with that name.
MS-DOS shows 'File not found' in this case, but FreeCOM
(and also Comcom64) can display invalid data, so let's
correct that. Since the required constant FA_DEVICE isn't
always present in `dos.h`, let's define it when necessary.

[https://github.com/FDOS/freecom/issues/181]

Before (C: is MFS, D: is FAT16):
~~~
C:\>dir nul
 Volume in drive C is IR DXXXXS C
 Directory of C:\

NUL                      0  10-30-25  6:55p
         1 file(s)              0 bytes
         0 dir(s)     49,839 Mega bytes free
C:\>d:

D:\>dir nul
 Volume in drive D has no label
 Volume Serial Number is 4A09-DBB4

 Directory of D:\

NUL                      0  10-30-25  6:55p
         1 file(s)              0 bytes
         0 dir(s)      42,698,752 bytes free
~~~

With patch (C: is MFS, D: is FAT16):
~~~
C:\>dir nul
 Volume in drive C is IR DXXXXS C
 Directory of C:\

File not found.

C:\>d:

D:\>dir nul
 Volume in drive D has no label
 Volume Serial Number is 4A09-DBB4
 Directory of D:\

File not found.
~~~

all: update files/documentation to include references to WFW 3.11

Now that patcher9x can also patch NDIS.386 in WFW 3.11, update any corresponding
files/documentation accordingly.

cpuspeed: add NDIS v4 speed patch suitable for WFW 3.11

WFW 3.11 uses a similar timing loop as Win9x in NDIS.386 and so will hang
during startup on a blank screen on a machine with a fast CPU.

Fortunately due to its shared history it is possible to take the existing
NDIS v1/v3 source and adapt it for WFW 3.11. Add the updated source as a
new NDIS v4 source, include it PATCH_CPU_SPEED_NDIS_ALL, and update files.c
to patch NDIS.386 if detected.

Resolves: https://github.com/JHRobotics/patcher9x/issues/23

feat: add support for alphanumeric CNPJ

Add Ampersand Ligature Variant for `ss03`

The feature `ss03` changes the ampersand to the traditional style.
When this feature is enabled the restyling of the ligature form
`ampersand_ampersand.liga` is not used because it does not exist.

This commit adds the part glyph `_part.ampersand.ss03`, adds the
ligature glyph `ampersand_ampersand.liga.ss03`, and modifies the
`ss03` feature to use the newly added ligature when the feature is
enabled.

The part glyph was only created to be a component for the newly
added ligature, like `_part.ampersand` is for
`ampersand_ampersand.liga`.

Linux/FreeBSD: Prevent mounting volumes on system directories and PATH (CVE-2025-23021, reported by SivertPL @__tfr)

Added security checks to prevent mounting VeraCrypt volumes on system directories (like /usr/bin) or directories in the user's PATH, which could theoretically allow execution of malicious binaries instead of legitimate system binaries.

Key changes:
- Block mounting on protected system directories (/usr, /bin, /lib, etc.)
  This restriction cannot be overridden
- Block mounting on directories present in user's PATH environment variable
  This can be overridden with --allow-insecure-mount flag
- Add visual warnings (red border, "[INSECURE MODE]") when mounting on PATH directories is allowed
- Handle symlinks properly when checking paths
- Add new error messages for blocked mount points

To override PATH-based restrictions only (system directories remain protected):
veracrypt --allow-insecure-mount [options] volume mountpoint

Security Impact: Low to Medium
The attack requires either:
- User explicitly choosing a system directory as mount point instead of using VeraCrypt's default mount points
- Or attacker having both filesystem access to modify favorites configuration AND knowledge of the volume password
Default mount points are not affected by this vulnerability.

Security: CVE-2025-23021

Linux/FreeBSD: Add absolute paths for system binaries to prevent path hijacking (CVE-2024-54187, collaboration with SivertPL @__tfr)

This commit fixes a critical security vulnerability where VeraCrypt could be tricked into executing malicious binaries with elevated privileges. The vulnerability has two severe implications:

1. When sudo's secure_path option is disabled, attackers could execute malicious binaries with root privileges by placing them in user-writable PATH directories (e.g., making "sudo mount" execute a malicious mount binary)

2. By placing a malicious sudo binary in PATH, attackers could intercept and steal the user's password when VeraCrypt prompts for sudo authentication

The vulnerability allowed attackers to place malicious binaries in user-writable directories that appear in PATH before system directories, potentially leading to privilege escalation and credential theft.

Key changes:
- Implement FindSystemBinary() to locate executables in secure system paths
- Replace all relative binary paths with absolute paths for system commands
- Add security checks for executable permissions
- Update process execution to use absolute paths for:
  * sudo
  * mount
  * fsck
  * terminal emulators
  * file managers
  * system utilities (hdiutil, mdconfig, vnconfig, lofiadm)

The fix ensures all system binaries are called using their absolute paths from secure system directories, preventing both privilege escalation through PATH manipulation and password theft through sudo hijacking.

Security: CVE-2024-54187

JS: Performance fix for chrome

Holy performance killer batman! Chrome was updating nodelists on
every change instead of batching them like firefox resulting in
exponentially worse performance. (Like "This fix made it go from
40 minutes to 7 seconds" exponentially)

CSS: Set contain on kint dumps to help client side performance

The contain and content-visibility properties are very new and
can actually break rendering entirely in different circumstances
for different browsers.

For now we'll stick to good old display:none and just hope contain
implementations get good enough to give us some perf down the line.