Revert "netatalk: update to version 3.1.13" #18337
Conversation
We received a report from Turris user on Turris support department that netatalk version 3.1.13 does not work properly. Process afpd says: INTERNAL ERROR Signal 11 because of that Apple Time Machine does not work as it should This was already reported to netatalk by different people on various GNU/Linux distributions like CentOS, AlmaLinux [1] [2] netatalk developer states [3]: ``` Generally, at this point I can only advice to stop using Netatalk. There are more pending CVEs that I currently don't have the bandwidth to work on. ``` [1] https://sourceforge.net/p/netatalk/bugs/669/ [2] https://sourceforge.net/p/netatalk/bugs/670/ [3] https://sourceforge.net/p/netatalk/mailman/message/37638871/ This reverts commit 165c562. Signed-off-by: Josef Schlehofer <[email protected]>
|
Wouldn't it be more appropriate to really just drop netatalk completely, ie. cherry pick commit 51e6778 instead of reverting to a known-to-be-vulnerable version? I'm aware that netatalk is hardly ever used on the open Internet, but given that ransomware is the thing of the 21st century, even exploits carried out using a local infected machine as a proxy doesn't seem to be too much of an absurd scenario... |
|
Since we are talking about OpenWrt 19.07, I am not so sure that we want to introduce more drastic changes like dropping this package. I think it is not a wrong solution to revert it, to have it working as it should, and once the fix is available update it one more time. Yes, it is going to be vulnerable. While checking it in Debian, I see that Stretch, Buster, Bullseye has this vulnerable version, too. Users do not care who is responsible for it or even why it does not work, when it was working, though. I don't think I want to say, user, I am so sorry, but the developer said that you should not use it anymore since it is vulnerable, I know it was working, but there isn't anything I can do. Well, IMHO, the better approach is indeed to fix it properly, but I don't have time to look at it, and I don't use this. I don't have any Apple devices. On the other hand, this was quick change to get it working and have satisfied users and customers. |
|
By looking at Netatalk/netatalk#174 , which should address reported issue (Netatalk/netatalk#175) and mentioned above in OP. I think for a few days, we can go back to previous version until the new version appears. :-) |
|
Users who have already installed 3.1.13 will not see this "update" - what you want is a package version like 3.1.13-2really3.1.12. |
|
@jefferyto You are right. That's somehow different than what it is in Turris OS. Thanks for spotting this! I will fix this. |
|
There is also a fix in progress in a Pull Request to Netatalk GitHub, seems to be nearing finalization, but not yet optimal: |
|
The main question how I see it is - Is it more broken when it allows root access to the router from any device in local network or when it crashes sometimes? And possibly a second one: Do we find it beneficial to actively re-include a vulnerability in the repo? |
|
It crashes all the time once you try to authorize yourself. Netatalk should be used only in a trusted local network as I going to quote openbsd/ports@68fb848. The question is do we want to have working software for users or not? If not, then they will throw it to trash bin. :) That's common response from users on our support department IMHO. |
|
By "crashes sometimes" I primarily referred to the two mentioned not much tested 3.1.13 fixes either of which can be applied temporarily just now instead of straight revert. (well, might be worth waiting just a bit in case of Netatalk/netatalk#174 (comment) ) |
|
I don't think "doing something useful while endangering the device I run on until the device gets compromised" == "working". Trusted network AFAIK doesn't usually mean everything inside has root access to the router. The mostly accepted security in depth approach is based on layered protection, which in this case, I think, usually means being inside local network should't be equal to having root on the router - that should be the next protection layer. |
|
19.07 / Re-introduce Netatalk 3.1.13 with: Linked to: |
Maintainer: @dangowrt
Compile tested: N/A
Run tested: N/A
Description:
It seems that only possible solution for users is to downgrade netatalk, which was working even though it is vulnerable to multiple CVEs issues (see reverted commit)
We received a report from Turris user on Turris support department that
netatalk version 3.1.13 does not work properly.
Process afpd says: INTERNAL ERROR Signal 11
because of that Apple Time Machine does not work as it should
This was already reported to netatalk by different people on various
GNU/Linux distributions like CentOS, AlmaLinux [1] [2]
netatalk developer states [3]:
And he also adds that the fix is working on.
[1] https://sourceforge.net/p/netatalk/bugs/669/
[2] https://sourceforge.net/p/netatalk/bugs/670/
[3] https://sourceforge.net/p/netatalk/mailman/message/37638871/