Opened 9 years ago

Closed 4 years ago

#48579 closed enhancement (fixed)

libsodium: use release download

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: stromnov (Andrey Stromnov)
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: haspatch Cc:
Port: libsodium

Description

The libsodium developers offer a release download, so the port should use it instead of the automatically generated download. This should eliminate the need to run autogen.sh.

However, since this would result in yet another nearly identical tarball being downloaded for this version, it would be best to wait to commit this until it can be combined with the next version update of this port.

Attachments (1)

libsodium-release.diff (1.1 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.

Download all attachments as: .zip

Change History (12)

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: libsodium-release.diff added

comment:1 Changed 9 years ago by stromnov (Andrey Stromnov)

comment:2 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Let's remember to do this the next time the version of libsodium is updated.

comment:3 Changed 7 years ago by kencu (Ken)

FYI - this ticket can be closed. This issue was taken care of in subsequent updates of libsodium.

comment:4 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

It was fixed in [c01042e6c2ab0d220f9cfe3582aa5ec43c65011b/macports-ports] but then unfixed in [f4bf9fe9c1040e908ad5f5f655d55912e617a75a/macports-ports]. It looks like this was done because the latest release 1.0.18 does not have any release downloads on GitHub. However, it does have them on the aforementioned site so that should probably be used instead.

Inexplicably, the project offers two different source code downloads of 1.0.18, one with the suffix "-stable" and the other without, and the two differ significantly. And the same happened for 1.0.17. Someone should explain to the developers that they're doing versioning wrong.

comment:5 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

I guess it is explicable after all:

This defect in their strategy has been brought to their attention before:

The versions marked with "-stable" are further fixes beyond those that were released in that version. These "stable" files will occasionally be stealth-updated with new fixes, meaning their checksums will change. So I suggest not using the "-stable" files for the portfile.

In addition, the portfile version is currently listed as "1.0.18-STABLE". I would change it to "1.0.18". Unfortunately MacPorts considers 1.0.18 to be less than 1.0.18-STABLE, so when this change i made, the epoch would need to be increased (unless we jump straight to 1.0.19 or later, which doesn't exist yet).

comment:6 Changed 4 years ago by hostep (Pieter Hoste)

@ryandesign

Can you consider upgrading libsodium to 1.0.18-STABLE somehow?

We are running against a segfault issue on macOS Catalina due to the old 1.0.18 version when we use PHP's 'sodium_crypto_pwhash_str' function.

You should be able to reproduce it: on macOS Catalina, install php72-sodium using macports (php73 and php74 and others might be affected as well) and then execute the following on the command line: php -r "sodium_crypto_pwhash_str('foo', 4, 67108864);"

It should give you "Segmentation fault: 11"

If I understand it correctly, homebrew had the same problem and fixed it by using the "stable" version: https://github.com/Homebrew/homebrew-core/issues/45074#issuecomment-552232462 (but I might be wrong)

Would be appreciated if you could have a look at this problem, since we are a bit stuck on this problem for now since upgrading to Catalina.

If I need to open a new ticket for this, let me know!

Thanks!

comment:7 in reply to:  6 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to hostep:

@ryandesign

Can you consider upgrading libsodium to 1.0.18-STABLE somehow?

It's not my port; it's Andrew's. But I will propose an update.

If I understand it correctly, homebrew had the same problem and fixed it by using the "stable" version: https://github.com/Homebrew/homebrew-core/issues/45074#issuecomment-552232462 (but I might be wrong)

It was proposed there that Homebrew should use the "stable" tarball, but that was rejected because that tarball changes over time, the same reason I mentioned above for it being unsuitable for us. They went with the "non-stable" original 1.0.18 release, as I proposed above, which doesn't contain the fix for the issue you're encountering.

Would be appreciated if you could have a look at this problem, since we are a bit stuck on this problem for now since upgrading to Catalina.

It is incumbent upon the developers of software to timely release new versions to fix bugs; it should not be our responsibility to pick and choose random commits between stable releases. As I mentioned above, please ask the developers to release a new numbered stable version. Since it has been over a year since they last did so, and since the last version doesn't work for you, we can update to something intermediate for now, but we do not want to be in the habit of doing so indefinitely. We want to distribute stable numbered versions that have been vetted by the developers.

comment:9 Changed 4 years ago by hostep (Pieter Hoste)

Hi @ryandesign

I have an update, we were able to fix our problem. We don't need the new source code, we just needed to rebuild the libsodium library from source by executing: sudo port -s upgrade --force libsodium

Here's my theory about what happened: 1) It looks like there is a bug in older Xcode versions (older then 11.2) on macOS Catalina: https://github.com/jedisct1/libsodium/issues/881 2) Macports probably build libsodium using such an older Xcode version 3) When we install libsodium from macports, it uses that pre-build buggy version and causes our issue 4) When we build libsodium from source ourselves (using Xcode 11.5), our problem is gone

So I think you just need to trigger a rebuild of libsodium with a non-buggy Xcode version and don't need newer source code of libsodium

Thanks!

comment:10 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Yes, older Xcode 11 versions have caused problems for us in many ports. We have a portgroup ports can include for working around such issues, and we could apply it to this port if it's still needed. If we're going to force a rebuild for that reason anyway, we may as well update to the latest stable, per my PR, since that's what upstream recommends at this point. (I still recommend upstream change their software release methodology; what they are doing now is not normal and is not helpful.)

comment:11 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: newclosed

In 01852af41498a024b5c9666f4f81daea7896b24c/macports-ports (master):

libsodium: Update to 1.0.18-20200728

It has been over a year since the 1.0.18 release, but the project
recommends using the stable branch which has further fixes. Rework the
Portfile to accommodate this.

The github portgroup livecheck tells you if the latest commit hash is
different. A custom livecheck on my server tells you the latest version
and date by checking the releases directory on their server. I wasn't
sure which one of these was more useful so I've left both in the
Portfile with the former activated for now.

Closes: #48579

Note: See TracTickets for help on using tickets.