netatalk-devel — Netatalk development mailing list (for developers)

Re: [Netatalk-devel] Netatalk --- charcnv.c:999 failure

[Andres V. <te...@sm...>]

Looks like bad filenames to me.

On 2/15/25 10:31, Daniel Markstedt wrote:
> Hi Andres,
> 
> This is a good catch. Thanks for the PRs earlier.
> Is this occurring with specific encoding settings in afp.conf, or is the 
> trigger particular UTF8 file names on the host file system?
> 
> Cheers,
> Daniel
> 
> On Saturday, February 15th, 2025 at 12:25 AM, Andres Valloud 
> te...@sm... <mailto:te...@sm...> wrote:
> 
>     Hi Daniel, I isolated one of the file name failures. The issue I see is
>     due to EILSEQ caused by file names not having valid UTF8 encoding.
>     After the conversion from UTF8 to UCS2 fails, netatalk will also
>     complain that the CNID database indexes are not in sync anymore.
> 
>     I recently submitted a PR so that the log includes a bit more
>     information about what is broken, without that I would not have found
>     the broken file names that easily. This has been integrated already,
>     thanks!
> 
>     Andres.
> 
>     _______________________________________________
>     Netatalk-devel mailing list
>     Net...@li...
>     <mailto:Net...@li...>
>     https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>     <https://lists.sourceforge.net/lists/listinfo/netatalk-devel>
> 

Re: [Netatalk-devel] Netatalk --- charcnv.c:999 failure

[Daniel M. <da...@mi...>]

Hi Andres,

This is a good catch. Thanks for the PRs earlier.
Is this occurring with specific encoding settings in afp.conf, or is the trigger particular UTF8 file names on the host file system?

Cheers,
Daniel

On Saturday, February 15th, 2025 at 12:25 AM, Andres Valloud te...@sm... wrote:

> Hi Daniel, I isolated one of the file name failures. The issue I see is
> due to EILSEQ caused by file names not having valid UTF8 encoding.
> After the conversion from UTF8 to UCS2 fails, netatalk will also
> complain that the CNID database indexes are not in sync anymore.
> 

> I recently submitted a PR so that the log includes a bit more
> information about what is broken, without that I would not have found
> the broken file names that easily. This has been integrated already,
> thanks!
> 

> Andres.
> 

> _______________________________________________
> Netatalk-devel mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel

[Netatalk-devel] Netatalk --- charcnv.c:999 failure

[Andres V. <te...@sm...>]

Hi Daniel, I isolated one of the file name failures.  The issue I see is 
due to EILSEQ caused by file names not having valid UTF8 encoding. 
After the conversion from UTF8 to UCS2 fails, netatalk will also 
complain that the CNID database indexes are not in sync anymore.

I recently submitted a PR so that the log includes a bit more 
information about what is broken, without that I would not have found 
the broken file names that easily.  This has been integrated already, 
thanks!

Andres.

Re: [Netatalk-devel] Request for opinion: Meson build system

[Daniel M. <da...@mi...>]

On Tuesday, February 27th, 2024 at 4:32 PM, Daniel Markstedt <da...@mi...> wrote:

> A question for you all: How would it affect you if Netatalk moved to the Meson build system?
> 
> The primary benefits that we over traditional GNU autotools are:
> 
> -   It's fast!
> -   Used by well-established open source projects such as qemu, mesa, freedesktop.org (eg dbus), Gnome, glib
>     
> -   The meson.build files have a transparent logic and are easy to update
>     
> -   The dependency search function works really well cross-platform so less user intervention with configure options is required
>     
> 
> 
> The main drawback is of course the disruption to package maintainers or sysadmins who like to roll their own binaries.
> 
> So before making the final decision, I want to hear the Voice of the Customer, as it were. :)
> 
> Here is the ticket in question: https://github.com/Netatalk/netatalk/issues/707
> 
> 
> 
> Cheers,
> Daniel

An update on this project:

Thank you to all of you who responded with feedback! We are committed to making the transition as seamless as possible.

The Meson build system is now available in the bleeding edge main branch and ready for testing. If you all have a chance to try this out, we would love to hear back about issues or missing features.

"meson" and "ninja" (sometimes packaged separately as "ninja-build") are required.

Instructions are captured in the INSTALL file: https://github.com/Netatalk/netatalk/blob/main/INSTALL

We also have GitHub CI actions yaml files that captures the concrete steps for building with Meson on many major OSes: https://github.com/Netatalk/netatalk/blob/main/.github/workflows/build.yml

(Solaris steps are missing here, but we've tested it successfully on Solaris 11.4 locally.)

The same files exist for netatalk 2.x in the branch-netatalk-2-4 branch.

Once any kinks have been worked out, we aim to have this in an upcoming 3.2.0 (and 2.4.0) release.

We are looking forward to getting your feedback!

On behalf of the Netatalk team,

Daniel

[Netatalk-devel] Request for opinion: Meson build system

[Daniel M. <da...@mi...>]

A question for you all: How would it affect you if Netatalk moved to the Meson build system?

The primary benefits that we over traditional GNU autotools are:

- It's fast!
-
Used by well-established open source projects such as qemu, mesa, freedesktop.org (eg dbus), Gnome, glib

- The meson.build files have a transparent logic and are easy to update
- The dependency search function works really well cross-platform so less user intervention with configure options is required

The main drawback is of course the disruption to package maintainers or sysadmins who like to roll their own binaries.

So before making the final decision, I want to hear the Voice of the Customer, as it were. :)

Here is the ticket in question: https://github.com/Netatalk/netatalk/issues/707

Cheers,
Daniel

[Netatalk-devel] Feedback Request: Deprecate Randnum exchange UAM

[Daniel M. <da...@mi...>]

Dear Netatalk community,

I'm here again to present another deprecation proposal, to understand how this would impact your use cases.

- Remove the Randnum UAM, while moving to WolfSSL as the backend for the DHX UAM.

The full discussion can be found in this ticket: https://github.com/Netatalk/netatalk/issues/358

TL;DR; OpenSSL 3.0 dropped support for DHCAST128 which backs the DHX UAM. The DHX UAM code still builds, but throws errors when a Classic Mac OS client tries to authenticate.

More and more OS distributions are migrating to OpenSSL 3.0, so this is getting to be a bigger and bigger obstacle for getting started with Netatalk.

The current plan is to use WolfSSL as a drop-in solution. WolfSSL has an OpenSSL compatibility layer which covers DHCAST123. However it does not implement the symbols that Randnum needs.

Decoupling DHX and Randnum turned out to be a huge effort, so we are proposing to remove Randnum altogether from Netatalk 3.x.

Randnum will continue to be supported in the Netatalk 2.x branch (probably by sacrificing DHX.)

There is an unofficial extension for DHX auth on Mac OS 9. And you always have the Clear Text UAM option if you absolutely need very old Mac OS clients to connect to your Netatalk 3.x server.

I'm very curious to hear your thoughts on this situation!

Best regards,
Daniel

Re: [Netatalk-devel] Feedback Request: Microsecond time stamp logging

[David R. <fra...@gm...>]

On Dec 15, 2023, at 4:58 AM, Hauke Fath <hf...@sp...> wrote:
> 
> On Fri, 15 Dec 2023 09:00:33 +0000, Daniel Markstedt wrote:
>> When you log to a file (the "log file" option), netatalk is hard 
>> coded to output a time stamp in this format: Dec 08 15:59:35.402141
>> 
>> However, it has recently been reported by a user that the microsecond 
>> granularity is causing incompatibility with a particular log 
>> management solution that they are using.
> 
> Well, my knee-jerk reaction: Netatalk shouldn't have to adapt to an 
> inflexible, effectively borken log parser.

And, further, changing the log format runs the near-certain risk of breaking many other (presumably also poorly-written and inflexible) things already parsing netatalk logs; ideally, this would be solved with a log format directive that defaults to the current format, which is how many other daemons handle this.  It's a little surprising to me that it's hardcoded, to be honest.  I could have sworn there was a format directive, but I must have dreamed it.

No, most of us probably don't *need* microsecond precision (though it seldom hurts), but beware making sudden changes in long-unchanged outputs, which are de facto standards whether we'd like them to be or not.

>> Off the top of my head, I can think of one reason for microsecond 
>> accuracy: Fine-grained performance profiling.
> 
> With faster machines, more things happen within a second. When the 
> events reported happened at distinctly different times, it makes a lot 
> of sense to provide the exact time stamp.

Basically this.  I've had situations where sub-millisecond precision has made the difference in diagnosing a race condition.


- Dave

Re: [Netatalk-devel] Feedback Request: Microsecond time stamp logging

[Hauke F. <hf...@sp...>]

On Fri, 15 Dec 2023 09:00:33 +0000, Daniel Markstedt wrote:
> When you log to a file (the "log file" option), netatalk is hard 
> coded to output a time stamp in this format: Dec 08 15:59:35.402141
> 
> However, it has recently been reported by a user that the microsecond 
> granularity is causing incompatibility with a particular log 
> management solution that they are using.

Well, my knee-jerk reaction: Netatalk shouldn't have to adapt to an 
inflexible, effectively borken log parser.

> In addition, I think the microsecond logging clutters the logs.

Run the log through sed(1) if you want the microseconds cut out?

> It's worth noting that Netatalk logs with second accuracy to syslog 
> by default on all systems I've looked at (probably controlled by a 
> system level log daemon?)

That's syslogd (on my NetBSD machine, at least ;) providing the time 
stamps.

The bug reporter is talking about having netatalk log to a *file*, in 
which case it provides its own timestamps.
 
> Off the top of my head, I can think of one reason for microsecond 
> accuracy: Fine-grained performance profiling.

With faster machines, more things happen within a second. When the 
events reported happened at distinctly different times, it makes a lot 
of sense to provide the exact time stamp.

My 0.02 EUR,
Hauke

-- 
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-21344

Re: [Netatalk-devel] Feedback Request: Microsecond time stamp logging

[Hauke F. <ha...@Es...>]

On Fri, 15 Dec 2023 09:00:33 +0000, Daniel Markstedt wrote:
> When you log to a file (the "log file" option), netatalk is hard 
> coded to output a time stamp in this format: Dec 08 15:59:35.402141
> 
> However, it has recently been reported by a user that the microsecond 
> granularity is causing incompatibility with a particular log 
> management solution that they are using.

Well, my knee-jerk reaction: Netatalk shouldn't have to adapt to an 
inflexible, effectively borken log parser.

> In addition, I think the microsecond logging clutters the logs.

Run the log through sed(1) if you want the microseconds cut out?

> It's worth noting that Netatalk logs with second accuracy to syslog 
> by default on all systems I've looked at (probably controlled by a 
> system level log daemon?)

That's syslogd (on my NetBSD machine, at least ;) providing the time 
stamps.

The bug reporter is talking about having netatalk log to a *file*, in 
which case it provides its own timestamps.
 
> Off the top of my head, I can think of one reason for microsecond 
> accuracy: Fine-grained performance profiling.

With faster machines, more things happen within a second. When the 
events reported happened at distinctly different times, it makes a lot 
of sense to provide the exact time stamp.

My 0.02 EUR,
Hauke

-- 
Hauke Fath                        <ha...@Es...>
Linnéweg 7
64342 Seeheim-Jugenheim
Germany

[Netatalk-devel] Feedback Request: Microsecond time stamp logging

[Daniel M. <da...@mi...>]

Dear Netatalk community:

Are you all relying on microsecond accuracy in netatalk logs?

When you log to a file (the "log file" option), netatalk is hard coded to output a time stamp in this format: Dec 08 15:59:35.402141

However, it has recently been reported by a user that the microsecond granularity is causing incompatibility with a particular log management solution that they are using.

In addition, I think the microsecond logging clutters the logs.

It's worth noting that Netatalk logs with second accuracy to syslog by default on all systems I've looked at (probably controlled by a system level log daemon?)

Off the top of my head, I can think of one reason for microsecond accuracy: Fine-grained performance profiling.

This is the ticket in question: https://github.com/Netatalk/netatalk/issues/580

If noone objects to changing to second accuracy in log time stamps, I will make the change in one week's time (Friday 12/22).

Thank you!

Daniel

Re: [Netatalk-devel] [Netatalk-admins] Request For Opinion: Deprecate FCE

[Jeff H. <jef...@gm...>]

"huge boon"

Agree!

I use afp between my linux server and my 2019 MacBook Pro running macOS
Venture 13.5.2. It seems to be superior to smb, which one other device
uses. I don't know if my Linux-macOS context uses the feature you describe
but I would be very unhappy if I had to switch to smb for all of my
devices. For a 6 month period or so, when I couldn't get this product
compiled on the linux server, I had to use smb everywhere and I was none
too happy.

On Sat, Nov 18, 2023 at 5:46 PM Daniel Markstedt <da...@mi...> wrote:

> Chris,
>
> Yes, very helpful. Thank you. I am convinced to keep the FCE feature in
> the upcoming 3.2 release cycle.
>
> I sincerely hope Apple doesn't kill off their AFP client in macOS any time
> soon. It's been a huge boon to be able to seamlessly do file sharing from
> very old Macs or even Apple IIs with the latest macOS clients using
> netatalk as a bridge software.
>
> As a side note, we actually got netatalk working fine on macOS hosts again
> earlier this year, serving AFP volumes on APFS file systems. Apple of
> course did away with their atalk kernel module for OSX 10+ years ago, so
> it's TCP/IP-only.
>
> Cheers,
> Daniel
> On Wednesday, November 15th, 2023 at 2:15 PM, Chris Devers <
> cd...@ed...> wrote:
>
> On Tue, Nov 14, 2023 at 11:39 PM Daniel Markstedt <da...@mi...>
> wrote:
>
>> For the example of the video production software:
>> Do you know for a fact that this software was sensitive to the Netatalk
>> FCE events specifically?
>> Or do you assume that it was based on the overall health of the system?
>>
>
> I’m a little reluctant to get *too* specific on a public mailing list, but
> yeah, the mainstream professional media software that people use for
> producing TV, film, advertising, streaming, etc media all frequently seem
> to use such capabilities.
>
> My sense is that when the applications detect that they’re writing to
> storage, they have mechanisms for determining whether the storage is local
> or remote, whether it supports various semantic operations, whether it
> supports things like normalized Unicode encoding for filenames, etc. And
> among the capabilities that get checked would be for things like file
> locking and filesystem change events, and depending on whether or not such
> functionality is determined to be available, certain features get enabled
> or disabled, as appropriate.
>
>> I guess what I’m trying to get at is whether Netatalk’s FCE is an
>> “industry standard” as it were, or if software had to be coded specifically
>> to be Netatalk aware, i.e. be modified for an enterprise rollout that
>> included Netatalk.
>>
>
> I haven't gone spelunking through the source code or the network packet
> traces, etc, but my sense is that the behavior tends to be as above:
> there’s a check for whether the storage is local or remote (more things,
> like Spotlight & Trash support, get turned on if the volume is “local”),
> and if the storage is “remote”, then the applications may tend to proceed
> not based on whether the volume is AFP/SMB/NFS/etc, but based on whether
> particular options, like filesystem change events, appear to be working or
> not.
>
> I wouldn’t want to force enterprise users to stay an old Netatalk version,
>> and miss out on security and stability improvements.
>
>
> Yeah, this is always the tension: upgrade or patch one thing, and
> everything else may need to update, too; hold back on updating one thing,
> and everything else can also be held back. Either way makes life harder for
> sysadmins.
>
> If someone is serving a fleet of older Macs and can’t realistically
>> migrate to Samba, I want Netatalk3 to remain a viable choice.
>>
>
> I think Apple are the primary drivers here, as AFP already can't be served
> from new Macs booting from APFS volumes, and the company has been signaling
> that macOS is likely to drop AFP client support in the future. Anyone still
> using AFP “professionally” has to be aware of this, and must be making
> plans to migrate to other options, if they haven't already done so.
>
> With video production, it can be the case that, for example, somebody buys
> a specialized piece of equipment, like a video ingest box, and maybe that
> piece of equipment is very expensive. It's sometimes the case that these
> products are sold but don’t really have upgradeable software or firmware,
> so they’re originally designed to work with particular Windows or Mac OS X
> / macOS versions, and they don’t necessarily work with later versions.
> Products like this can put people in a bind, because they have a
> workstation that’s older, but still doing useful work, and the replacement
> cost might be prohibitive, so they keep it on an older operating system
> version, and in turn might also have to hold back upgrades of other systems
> — like the AFP file server — because then they’re going down the rabbit
> hole of having to come up with a new matrix of compatible versions of
> everything they need to manage. Also, periods of downtime due to upgrades &
> testing can lead to lost revenue, which can further lead to a reluctance to
> make any changes if the status quo is “stable enough”, “secure enough”,
> etc.
>
> My sense is that anyone in a situation like this realizes that it's not a
> great scenario, and they’re eager to migrate to something better — like
> Samba, if possible, but other options exist as well. But the transition
> process can be disruptive, so there’s an instinct to stick with tools (such
> as AFP and its existing FCE support, even if it’s imperfect) that are known
> to be “good enough, for now”.
>
> Helpful?
>
>
> _______________________________________________
> Netatalk-devel mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>

Re: [Netatalk-devel] [Netatalk-admins] Request For Opinion: Deprecate FCE

[Daniel M. <da...@mi...>]

Chris,

Yes, very helpful. Thank you. I am convinced to keep the FCE feature in the upcoming 3.2 release cycle.

I sincerely hope Apple doesn't kill off their AFP client in macOS any time soon. It's been a huge boon to be able to seamlessly do file sharing from very old Macs or even Apple IIs with the latest macOS clients using netatalk as a bridge software.

As a side note, we actually got netatalk working fine on macOS hosts again earlier this year, serving AFP volumes on APFS file systems. Apple of course did away with their atalk kernel module for OSX 10+ years ago, so it's TCP/IP-only.

Cheers,
Daniel
On Wednesday, November 15th, 2023 at 2:15 PM, Chris Devers <cd...@ed...> wrote:

> On Tue, Nov 14, 2023 at 11:39 PM Daniel Markstedt <da...@mi...> wrote:
>
>> For the example of the video production software:
>> Do you know for a fact that this software was sensitive to the Netatalk FCE events specifically?
>> Or do you assume that it was based on the overall health of the system?
>
> I’m a little reluctant to get *too* specific on a public mailing list, but yeah, the mainstream professional media software that people use for producing TV, film, advertising, streaming, etc media all frequently seem to use such capabilities.
>
> My sense is that when the applications detect that they’re writing to storage, they have mechanisms for determining whether the storage is local or remote, whether it supports various semantic operations, whether it supports things like normalized Unicode encoding for filenames, etc. And among the capabilities that get checked would be for things like file locking and filesystem change events, and depending on whether or not such functionality is determined to be available, certain features get enabled or disabled, as appropriate.
>
>> I guess what I’m trying to get at is whether Netatalk’s FCE is an “industry standard” as it were, or if software had to be coded specifically to be Netatalk aware, i.e. be modified for an enterprise rollout that included Netatalk.
>
> I haven't gone spelunking through the source code or the network packet traces, etc, but my sense is that the behavior tends to be as above: there’s a check for whether the storage is local or remote (more things, like Spotlight & Trash support, get turned on if the volume is “local”), and if the storage is “remote”, then the applications may tend to proceed not based on whether the volume is AFP/SMB/NFS/etc, but based on whether particular options, like filesystem change events, appear to be working or not.
>
>> I wouldn’t want to force enterprise users to stay an old Netatalk version, and miss out on security and stability improvements.
>
> Yeah, this is always the tension: upgrade or patch one thing, and everything else may need to update, too; hold back on updating one thing, and everything else can also be held back. Either way makes life harder for sysadmins.
>
>> If someone is serving a fleet of older Macs and can’t realistically migrate to Samba, I want Netatalk3 to remain a viable choice.
>
> I think Apple are the primary drivers here, as AFP already can't be served from new Macs booting from APFS volumes, and the company has been signaling that macOS is likely to drop AFP client support in the future. Anyone still using AFP “professionally” has to be aware of this, and must be making plans to migrate to other options, if they haven't already done so.
>
> With video production, it can be the case that, for example, somebody buys a specialized piece of equipment, like a video ingest box, and maybe that piece of equipment is very expensive. It's sometimes the case that these products are sold but don’t really have upgradeable software or firmware, so they’re originally designed to work with particular Windows or Mac OS X / macOS versions, and they don’t necessarily work with later versions. Products like this can put people in a bind, because they have a workstation that’s older, but still doing useful work, and the replacement cost might be prohibitive, so they keep it on an older operating system version, and in turn might also have to hold back upgrades of other systems — like the AFP file server — because then they’re going down the rabbit hole of having to come up with a new matrix of compatible versions of everything they need to manage. Also, periods of downtime due to upgrades & testing can lead to lost revenue, which can further lead to a reluctance to make any changes if the status quo is “stable enough”, “secure enough”, etc.
>
> My sense is that anyone in a situation like this realizes that it's not a great scenario, and they’re eager to migrate to something better — like Samba, if possible, but other options exist as well. But the transition process can be disruptive, so there’s an instinct to stick with tools (such as AFP and its existing FCE support, even if it’s imperfect) that are known to be “good enough, for now”.
>
> Helpful?

Re: [Netatalk-devel] [Netatalk-admins] Request For Opinion: Deprecate FCE

[Daniel M. <da...@mi...>]

Chris,

Ah yes you’re right, I didn’t create a ticket (yet) for this one.
The mailing list archive is a fine place for recording this conversation. :)

Thanks again for leaning in with a concrete use case from your experience.
This really helps me contextualize why these features exist in the first place.

For the example of the video production software:
Do you know for a fact that this software was sensitive to the Netatalk FCE events specifically?
Or do you assume that it was based on the overall health of the system?

I guess what I’m trying to get at is whether Netatalk’s FCE is an “industry standard” as it were, or if software had to be coded specifically to be Netatalk aware, i.e. be modified for an enterprise rollout that included Netatalk.

I wouldn’t want to force enterprise users to stay an old Netatalk version, and miss out on security and stability improvements.
If someone is serving a fleet of older Macs and can’t realistically migrate to Samba, I want Netatalk3 to remain a viable choice.

Cheers!

Daniel

On Wed, Nov 15, 2023 at 6:27 AM, Chris Devers <[cd...@ed...](mailto:On Wed, Nov 15, 2023 at 6:27 AM, Chris Devers <<a href=)> wrote:

> Hello, me again. I’ve commented on a couple of Github discussions recently, but I don’t see a Github link on this one, so I’m responding to the mailing list instead.
>
> On Sat, Nov 4, 2023 at 11:42 AM Daniel Markstedt <da...@mi...> wrote:
>
>> Would getting rid of FCE (Filesystem Change Events) have an averse impact on your netatalk deployments?
>
> I’m pretty sure this would have been a problem for us.
>
> My employer makes shared storage servers for video production workflows, and it's common for the mainstream video editing applications to make use of filesystem change notifications in various ways, e.g. “someone just added a new file”, “someone just updated a file”, “someone has a file open for writing”, etc.
>
> If this functionality weren’t available, then the behavior can degrade in various ways, depending on the applications in question and the workflows being used. Optimistically, the software could just end up, say, re-scanning the contents of the volume repeatedly, looking for changes that may or may not have occurred; this might hurt performance a bit, but perhaps not that badly, depending on the particulars. In other cases though, the software could end up doing “incorrect” things, like trying to regenerate an index database that is already being updated or has recently been updated, or (perhaps) ignoring the fact that another client already has a file open for writing. These are just examples; I imagine that there are lots of weird edge cases that could arise in particular scenarios.
>
> The “good” news, in our case, is that we deprecated AFP/Netatalk support a couple years ago, so removing the functionality at this point would have no impact on us anymore.
>
> It’s possible that other “enterprise” / “professional” users of Netatalk/AFP are still using this functionality, but as Apple themselves continue to phase out AFP support, this is mainly going to be relevant for people who are for various reasons running older Mac workstations — and if that’s the case, maybe they can & should also just run an older version of Netatalk, too.
>
> --
> Chris Devers

[Netatalk-devel] Request For Opinion: Deprecate FCE

[Daniel M. <da...@mi...>]

Dear Netatalk community,

In the ongoing effort of streamlining the codebase, this suggestion might be the most controversial yet:

Would getting rid of FCE (Filesystem Change Events) have an averse impact on your netatalk deployments?
Do you know of anyone who relies on its API or logging for any kind of mission critical feature?

For the uninitiated, FCE is an API that lets you build applications that react on changes to files on the shared volume. Docs here:
https://netatalk.sourceforge.io/3.1/htmldocs/configuration.html#fce

The argument for deprecation is twofold: For one, it's a fairly complex feature with 9 events and 8 dedicated afp.conf options:
https://netatalk.sourceforge.io/3.1/htmldocs/afp.conf.5.html#fceconf

And secondly, it's has long-outstanding bugs such as:
https://github.com/Netatalk/netatalk/issues/122

I'd love to get your opinions on this!

Cheers,
Daniel

[Netatalk-devel] Request for Comment: Deprecate afprun functionality

[Daniel M. <da...@mi...>]

Dear Netatalk users,

To continue with our mission to make Netatalk safer and more maintainable, I would like to propose removing "afprun" functionality from the next point release of Netatalk (3.2.0).

Ticket for tracking: https://github.com/Netatalk/netatalk/issues/550

What this means, is that the following options will be removed:

- preexec
- root preexec

- postexec
- root postexec
- preexec close
- root preexec close
- stat vol

This code constitutes a major opportunity to run arbitrary shell commands (with root privileges) on the host, with all sorts of security implication.

Do you have deployments of Netatalk that rely on the above?
If so, we would love to know more about your use case!

Thank you!

Daniel

Re: [Netatalk-devel] [Netatalk-admins] Request for Comment: Deprecate CNID backends

[Daniel M. <da...@mi...>]

Hi Andres,

Thanks for your suggestion. We have an option for CNID dircachesize in afp.conf already. Is this akin to what you are asking for? The documentation says:

====
dircachesize = number (G)

    Maximum possible entries in the directory cache. The cache stores directories and files. It is used to cache the full path to directories and CNIDs which considerably speeds up directory enumeration.

    Default size is 8192, maximum size is 131072. Given value is rounded up to nearest power of 2. Each entry takes about 100 bytes, which is not much, but remember that every afpd child process for every connected user has its cache.
====

See https://netatalk.sourceforge.io/3.1/htmldocs/afp.conf.5.html

Also, "dbd" is what we call the CNID backend in question. We have some documentation in the manual: https://netatalk.sourceforge.io/3.1/htmldocs/configuration.html#CNID-backends

Best,
Daniel

------- Original Message -------
On Tuesday, October 3rd, 2023 at 7:23 AM, Andres Valloud <te...@sm...> wrote:


> 
> 
> Hi, for dbd (did you mean bdb?), you might also consider adding a
> db_param file with e.g.
> 
> cachesize 131072
> 
> by default.
> 
> Andres.
> 
> On 10/2/23 2:23 PM, Daniel Markstedt wrote:
> 
> > Dear Netatalk community,
> > 
> > The next step in the effort to reduce the tech debt and improve the
> > maintainability of Netatalk:
> > Evaluating the utility of, and deprecating several little-used CNID
> > backends.
> > 
> > At the time of writing, Netatalk has accumulated no less than 5 CNID
> > backends.
> > They are:
> > 
> > * cdb
> > * dbd
> > * last
> > * mysql
> > * tdb
> > 
> > The dbd backend has been the default for over a decade.
> > Is there anyone in the crowd here who actively use any of the other four
> > today?
> > We are considering deprecating all four, unless there is a concrete
> > usecase that dbd cannot fulfill.
> > 
> > See this github ticket for additional context and discussion:
> > https://github.com/Netatalk/netatalk/issues/508
> > https://github.com/Netatalk/netatalk/issues/508
> > 
> > Thank you!
> > 
> > Daniel
> > 
> > _______________________________________________
> > Netatalk-admins mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/netatalk-admins

[Netatalk-devel] Request for Comment: Deprecate CNID backends

[Daniel M. <da...@mi...>]

Dear Netatalk community,

The next step in the effort to reduce the tech debt and improve the maintainability of Netatalk:
Evaluating the utility of, and deprecating several little-used CNID backends.

At the time of writing, Netatalk has accumulated no less than 5 CNID backends.
They are:

- cdb
- dbd
- last
- mysql
- tdb

The dbd backend has been the default for over a decade.
Is there anyone in the crowd here who actively use any of the other four today?
We are considering deprecating all four, unless there is a concrete usecase that dbd cannot fulfill.

See this github ticket for additional context and discussion:
https://github.com/Netatalk/netatalk/issues/508

Thank you!

Daniel

Re: [Netatalk-devel] CVE-2022-45188 and CVE-2022-22995

[Daniel M. <mar...@gm...>]

Andy,

The main development branch now contains a patch for CVE-2022-45188.
It will be included in the next mainline release of Netatalk.

Best,
Daniel

On Thu, Feb 9, 2023 at 10:43 PM Daniel Markstedt <mar...@gm...>
wrote:

> Hi Andy,
>
> Looking at the commit log for 3.0.14 I don't think there were explicit
> fixes for either of those CVEs.
> I think it's safe to say that both advisories are still outstanding.
>
> Best,
> Daniel
>
> On Wed, Jan 11, 2023 at 7:02 AM Andrew Bauer <kni...@ou...>
> wrote:
>
>> Hello -
>>
>> These CVE's were reported against the fedora netatalk 3.0.13 package:
>>
>> CVE-2022-45188 netatalk: heap-based buffer overflow resulting in code
>> execution via a crafted .appl
>> https://nvd.nist.gov/vuln/detail/CVE-2022-45188
>>
>> CVE-2022-22995 netatalk: default configuration allows the arbitrary
>> writing of files
>> https://nvd.nist.gov/vuln/detail/cve-2022-22995
>>
>> Have either of these been addressed in the recent 3.0.14 release? I do
>> not see direct mention of these CVE's in the release notes on github.
>>
>> Thanks,
>> Andy
>>
>> _______________________________________________
>> Netatalk-devel mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>
>

Re: [Netatalk-devel] Sonar permissions

[Daniel M. <mar...@gm...>]

Hi Ralph,

Thanks for that. I made the scan setting more permissive (any user) but it
turns out there is a limitation with Github as well.
It won't pass tokens from the main repo to a job running on a forked repo.
https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow

So I merged a small configuration change to main to only run Sonar scans on
PRs originating from within the main repo.
This way we at least squelch the false failed scans noise.

BTW, I have a dozen PRs ready for your review. Nothing complex, but good to
get your eyes on them.

Thanks!
Daniel


On Mon, Mar 27, 2023 at 5:14 AM Ralph Boehme <sl...@sa...> wrote:

> Hi Daniel,
>
> On 3/26/23 23:46, Daniel Markstedt wrote:
> > I think it makes more sense to allow code scanning on all PRs.
> > If you make me admin of the Sonar project I can try to figure out the
> > permissions.
>
> I've added you to the owner group.
>
> Cheers!
> -slow
>
>

Re: [Netatalk-devel] Sonar permissions

[Ralph B. <sl...@sa...>]

Hi Daniel,

On 3/26/23 23:46, Daniel Markstedt wrote:
> I think it makes more sense to allow code scanning on all PRs.
> If you make me admin of the Sonar project I can try to figure out the 
> permissions.

I've added you to the owner group.

Cheers!
-slow

[Netatalk-devel] Sonar permissions

[Daniel M. <mar...@gm...>]

Hi Ralph,

It turns out Sonar scanning is only permitted on PRs submitted by project
members.
If the branch originate from a fork, the scan will fail with:

ERROR: Project not found. Please check the 'sonar.projectKey' and
'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or
contact the project administrator

I think it makes more sense to allow code scanning on all PRs.
If you make me admin of the Sonar project I can try to figure out the
permissions.

Best,
Daniel

[Netatalk-devel] master -> main

[Ralph B. <sl...@sa...>]

Hi!

I've now renamed the branch from master to main. github suggested the 
following commands to adjust the local repo:

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba

Re: [Netatalk-devel] Sonarcloud scanning

[Daniel M. <mar...@gm...>]

....aaaand we have an initial report :)
https://sonarcloud.io/summary/overall?id=Netatalk_netatalk

BTW we may want to turn off the code coverage quality gate.
Getting 80%+ UT coverage seems like a tall order for this codebase.

On Sat, Feb 25, 2023 at 3:09 PM Daniel Markstedt <mar...@gm...>
wrote:

> Thanks! Here's a PR for the Sonar scan build configuration.
> https://github.com/Netatalk/netatalk/pull/225
>
> Once this gets merged to master I expect the quality gates to take effect.
>
> On Sat, Feb 25, 2023 at 12:54 PM Ralph Boehme <sl...@sa...> wrote:
>
>> On 2/25/23 20:02, Daniel Markstedt wrote:
>> > Did you configure the Sonar secret for the GitHub action (on the GitHub
>> > side)?
>>
>> should be done now.
>>
>>

Re: [Netatalk-devel] Sonarcloud scanning

[Daniel M. <mar...@gm...>]

Thanks! Here's a PR for the Sonar scan build configuration.
https://github.com/Netatalk/netatalk/pull/225

Once this gets merged to master I expect the quality gates to take effect.

On Sat, Feb 25, 2023 at 12:54 PM Ralph Boehme <sl...@sa...> wrote:

> On 2/25/23 20:02, Daniel Markstedt wrote:
> > Did you configure the Sonar secret for the GitHub action (on the GitHub
> > side)?
>
> should be done now.
>
>

Re: [Netatalk-devel] Sonarcloud scanning

[Ralph B. <sl...@sa...>]

On 2/25/23 20:02, Daniel Markstedt wrote:
> Did you configure the Sonar secret for the GitHub action (on the GitHub 
> side)?

should be done now.