Re: Port sync is broken: Error: Failed to verify signature for ports tree!

[grey]

I am guessing this was fixed?

Regardless, I can't seem to reproduce a failed signature verification locally.

Output with debug and verbose flags added below:

% sudo port -d -v sync
--->  Updating the ports tree
Synchronizing local ports tree from
rsync://rsync.macports.org/macports/release/tarballs/ports.tar
DEBUG: system: /usr/bin/rsync -rtzvl --delete-after
--include=/ports.tar --include=/ports.tar.rmd160 --exclude=*
rsync://rsync.macports.org/macports/release/tarballs/
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs

Willkommen auf dem RSYNC-server auf ftp.fau.de.
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de.
Not all of our mirrors are available through rsync.


receiving file list ... done
./

sent 68 bytes  received 99 bytes  66.80 bytes/sec
total size is 125511680  speedup is 751566.95
DEBUG: successful verification with key
/opt/local/share/macports/macports-pubkey.pem
DEBUG: Using bsdtar with HFS+ compression (if valid)
DEBUG: system: bsdtar --hfsCompression -C
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/tmp
-xf 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports.tar
DEBUG: system: chmod -R a+r
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
DEBUG: system: /opt/local/bin/portindex
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports
Creating port index in
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports

Total number of ports parsed:0
Ports successfully parsed:0
Ports failed:0
Up-to-date ports skipped:39123

On Sat, Jun 1, 2024 at 6:57 AM Sergio Had  wrote:
>
> sent 78567 bytes  received 194729 bytes  20244.15 bytes/sec
>
> total size is 125495808  speedup is 459.19
>
> Error: Failed to verify signature for ports tree!
>
> port sync failed: Synchronization of 1 source failed

Re: CI are forcing tests for ports where tests are disabled

[grey]

I think I may have run into a similar issue with how tests have
changed in CI with 2.9.x MacPorts and the OpenSSH 9.7p1 PR I submitted
yesterday:

https://github.com/macports/macports-ports/pull/22981

Going back to reverting to 9.6p1 locally and running port -d -v test I
see that it fails with the same error; whereas when the CI checks for
that ran with my PR in December of 2023, the CI checks passed.

The man page for port test is pretty slim:
  test
   Tests portname.

So I am guessing this is the spot to reference for more descriptive
explanations of test.cmd and test.args
https://guide.macports.org/#reference.phases.test

Whereas the net/openssh Portfile just has these defined at the moment:

test.runyes
test.target tests

I've include the output of manually invoking "make test" in the
following Trac issue I opened regarding this CI buildbot failure:

https://trac.macports.org/ticket/69478#comment:2

Which, as you can see, ends with "all tests passed"; so I don't think
this is an issue with upstream/OpenSSH's tests. Not to mention,
running make tests from the OpenSSH tarball is really quite time
consuming and probably not the best use of CI buildbot resources?

I can't make heads or tails of this commit from 2.9.0 which introduced
the "simple default tests for all ports"
https://github.com/macports/macports-base/commit/ddc26554e6ed49ce8501069b967284739fa6d34e

But, I am guessing, it's either not that simple, or at a minimum, I
might need some additional insights into how to placate it.

Thanks!

Re: Python dependencies (was: MacPorts 2.9.0-beta1 now available for testing)

[grey]

Thanks for the explanation! I had done some dependency walks with some
pointers from neverpanic, but hadn't been able to make heads or tails
of why some of the things were the way they were.

On Tue, Jan 2, 2024 at 8:20 AM Joshua Root  wrote:
>
> On 2/1/2024 11:24, grey wrote:
> > Installing llvm-17 goes OK, but:
> >
> > Why are python310 and python311 considered dependencies if I already
> > have python312 installed and selected? Pretty sure that some other BSD
> > ports systems I use do not seem to regress like MacPorts in similar
> > dependency walks, the fact that my MacPorts now has three versions of
> > Python installed seems a bit wonky to me.
>
> Ports usually depend on a specific version of python so the build
> environment will be consistent. The MacPorts default python version only
> just changed from 3.11 to 3.12, so some ports just haven't been switched
> over yet. Others aren't compatible with the newer version. And then...
> there's this specific example.
>
> Python 3.11 and later need to be built with a C11 compiler. On older
> systems, Xcode doesn't ship one, so the C11 compiler that gets used is
> one of the clang-* ports. The dependency on python311 in llvm-17
> shouldn't be hard to switch over to python312, but python312 will also
> have to be configured to avoid using the clang versions that use it.
>
> The python310 dependency comes from libpsl, which is an indirect
> dependency of cmake, which is needed to build all recent llvm versions.
> This is trickier because all of the C11 capable clang versions need
> cmake. We could possibly only hold back the python used by libpsl on
> platforms without C11 support in Xcode, though that would mean a less
> tested configuration for some users. Or it could probably be solved with
> more use of *-bootstrap ports.
>
> - Josh

Re: MacPorts 2.9.0-beta1 now available for testing

[grey]

Preliminary testing for the handful of ports for which I am listed as
a maintainer went off without a hitch!

However, I have a question which maybe someone who is a bit more of a
Python wizard can explain for me? Note: I don't think this is an issue
with the beta at all.

For example, I performed the following (this is on a system running
the most recent Sonoma 14.3 beta with the MacPorts 2.9.0 beta
package):

% sudo port -fp uninstall --follow-dependents installed
% sudo port selfupdate
% sudo port install libressl (I do this as a libressl port
co-maintainer to preempt any TLS dependencies that may come up)
% sudo port install python312 (may as well start off fresh with the
latest and greatest! Right?)
% sudo port select --set python python312
% sudo port select --set python3 python312
% rehash (for good measure)
% sudo port install llvm-17 (again, going with the latest and greatest)

The following dependencies will be installed:

 autoconf
 automake
 brotli
 cmake
 cmake-bootstrap
 curl
 curl-ca-bundle
 icu
 libarchive
 libb2
 libcxx
 libidn2
 libpsl
 libtool
 libunistring
 libuv
 libxml2
 libyaml
 llvm_select
 lz4
 lzo2
 m4
 nghttp2
 py311-build
 py311-cython-compat
 py311-installer
 py311-packaging
 py311-pygments
 py311-pyproject_hooks
 py311-setuptools
 py311-wheel
 py311-yaml
 pygments_select
 python310
 python311
 python3_select-311
 python_select-311
 xar
 zstd
Continue? [Y/n]:

Installing llvm-17 goes OK, but:

Why are python310 and python311 considered dependencies if I already
have python312 installed and selected? Pretty sure that some other BSD
ports systems I use do not seem to regress like MacPorts in similar
dependency walks, the fact that my MacPorts now has three versions of
Python installed seems a bit wonky to me.

Anyway, maybe there isn't a good answer to this but it raised an
eyebrow so I thought I would defer to those wiser than I for an
explanation.

Thank you and I hope everyone is having a Happy 2024!

Re: More classes of maintainer

[grey]

To chime in on this, and take what I write with a grain of salt since
I still feel relatively new to MacPorts, but too much dependence on
GitHub gives me the heebie jeebies.

I realize Trac isn't perfect, but there are far worse issue tracking
systems that I have administered over the decades.

If anything, I think it would be fantastic (though obviously, a non
trivial amount of effort) if MacPorts were more self sufficient and
self hosted and treated closed source for-profit proprietary entities
such as GitHub as read-only mirrors; or maybe facilitated other git
front ends such as codeberg, etc.?

Request for Comments: remediating OpenSSH segfaults with specific versions of XCode on Intel (Ventura?)

[grey]

Hello!

This https://trac.macports.org/ticket/67539 was opened about a week
ago, and while I have not been able to replicate it on any of my
systems locally, it seems as if the root cause is due to XCode's clang
(related: https://github.com/llvm/llvm-project/issues/57692 and
https://infosec.exchange/@harrysintonen/110508989501024969 as
referenced in https://trac.macports.org/ticket/67539#comment:34 )

I am guessing: that the same underlying issue may also be responsible
for https://trac.macports.org/ticket/67442 though in both instances, I
haven't been able to replicate the segfaults presumably because:

1. I am mostly working on Apple Silicon systems.
2. When I retrieved an Intel based Apple system of mine to test
further, it's too old to be running recent macOS and XCode versions,
and llvm16/-devel from MacPorts doesn't exhibit such issues
(presumably because the bug in clang was patched since then).

So, longer story shorter: I can't presently replicate either of these
bugs with any of the systems I have at my disposal, making testing
potential fixes challenging.

Simply adding more to compiler.blacklist-append seems as if it also
might not be so great as a strategy, since that isn't quite granular
enough to distinguish between whether the clang/Xcode is Intel or
Apple Silicon either.

@piru provided a potential heuristic here:
https://trac.macports.org/ticket/67539#comment:39

As I theorized here: https://trac.macports.org/ticket/67539#comment:41
maybe we could use @piru's heuristic in a manner similar to how Jeremy
Hu added some smarts for wavpack compiler preferences here:
https://github.com/macports/macports-ports/commit/6fb35a1f2843454f08ef5027dfe0e3db59016d99

However, after asking for extra sets of eyeballs on IRC and seeing
nothing but mplog in the messages for the past 45+ minutes now, I
figure asking for additional perspective and insights from the
Developers mailing list is hopefully an acceptable course of action?

I am a little bit in over my head with this one.

At a minimum, if any MacPorts contributors can for starters: replicate
the issue, that would be helpful as in turn, they can presumably also
test potential fixes, whereas I haven't even been able to replicate
the segfaults leaving me a bit at a loss.

Thank you in advance for any assistance you may be able to provide!

Re: The State of Rust in MacPorts Today

[grey]

This is a tangential, so please forgive me if this seems as if it is
the wrong time to bring this up, but I seem to have some Rustaceans
who may know more about this than I.

I was recently seeing if there might be a way to improve upon the
FFmpeg ports (there are currently three: ffmpeg, fffmpeg-devel and
ffmpeg-upstream, though two of them are at the same version presently)
to reduce the number of dependencies. While I was able to make a go of
it successfully and included an attempt at a Portfile here:
https://trac.macports.org/ticket/66424# in the comments Ken suggested
that since the current MacPorts for FFmpeg have rust as a dependency,
that brings in a flood of other dependencies.

To be honest, I am unsure why FFmpeg would require rust (it doesn't in
my builds from upstream's repository if cloning from source nor in my
Portfile using a versioned release), and it seems as if such things
may be better separated into a variant, but even in the occasion where
rust is considered required, does rust really have that many
dependencies? I guess it is the Kolmogorov complexity reduction spirit
in me, but am I crazy for thinking that a dependency audit and
minimizing such things might be worthwhile (probably for more than
merely FFmpeg, perhaps even the rust MacPort itself)?

Thank you for any insights into a rather unrelated matter.

On Tue, Dec 13, 2022 at 5:21 PM Kirill A. Korinsky via macports-dev
 wrote:
>
> Chris,
>
> Clearly some thought has to be given to how to ensure the dependency tree 
> does not get too long. We don’t want, when a new OS comes out for it to have 
> to build tens of rust versions, just to ultimately bootstrap the last one. 
> That might just be keeping the first bootstrap port, mrustc new enough at all 
> times such that the list is kept manageable.
>
>
> Unfortunately mrust supports to build rust up to 1.54.
>
> As soon as upstream of mrust is updated compiler to something never, I'll 
> update the port and short the tree.
>
> --
> wbr, Kirill
>
> On 13. Dec 2022, at 18:16, Christopher Jones  wrote:
>
> Hi,
>
> On 13 Dec 2022, at 5:07 pm, Kirill A. Korinsky via macports-dev 
>  wrote:
>
> David,
>
> the idea is creating a dependency chain:
>
> Port rust (version 1.66) depends on rust-1.65 to be build;
> Port rust-1.65 depends on rust-1.64 to be build;
> Port rust-1.64 depends on rust-1.63 to be build;
> ...
> Port rust-1.56 depends on rust-1.55 to be build;
> Port rust-1.55 depends on rust-1.54 to be build;
> Port rust-1.54 depends on mrsutc to be build.
>
> :)
>
> When someone would like to add rust 1.67, he need to add port rust-1.66 which 
> should be used as bootstrap compiler.
>
> I hate this way, but it is the only way to bootstrap it from scratch.
>
>
> Clearly some thought has to be given to how to ensure the dependency tree 
> does not get too long. We don’t want, when a new OS comes out for it to have 
> to build tens of rust versions, just to ultimately bootstrap the last one. 
> That might just be keeping the first bootstrap port, mrustc new enough at all 
> times such that the list is kept manageable.
>
> Chris
>
>
>
> When mrust had support new rust, we may cut the tree by removing a lot of 
> unused ports.
>
>
> --
> wbr, Kirill
>
> On 13. Dec 2022, at 17:53, David Gilman  wrote:
>
> The work on mrustc is novel but I don't think it solves the issues we have 
> here. On modern systems MacPorts uses bootstrap compilers provided by Rust 
> upstream. MCL's bootstrap compilers are for older systems.
>
> To update rust, my understanding is that you have to do the usual work of 
> rebasing patches (my PR), but you also have to provide the binaries for older 
> systems which I could not provide.
>
>
> On Tue, Dec 13, 2022, 11:07 AM Kirill A. Korinsky via macports-dev 
>  wrote:
>>
>> Folks,
>>
>> From the third hand we may build our own bootstrap chain of rust from 
>> scratch.
>>
>> Or almost.
>>
>> We have a https://ports.macports.org/port/mrustc/details/ which is able to 
>> bootstrap 1.54 rust on x86_64 and arm64.
>>
>> Unfortunately support of i386 isn't yet finished at upstream. I plan to fix 
>> it, but it requires time and availability of hardware to test it :)
>>
>> I do have a commits which implements rust bootstrap by cahin: mrustc -> rust 
>> 1.54 -> rust 1.55 -> rust 1.56; I can start to open PRs to move step-by-step 
>> and in month we'll have the last rust via this chain.
>>
>> --
>> wbr, Kirill
>>
>> On 13. Dec 2022, at 16:49, Christopher Jones  
>> wrote:
>>
>> Hi,
>>
>> In my opinion, hosting and maintaining these ‘bootstrap’ compilers outside 
>> the macports infrastructure was a poor choice, for all the reasons you 
>> mention below. I thought this at the time it was done, and even more so now.
>>
>> Personally, I would suggest you think about a change to how the rust 
>> compiler is package, to mirror a bit how things are done with gcc and clang. 
>> Namely, move to a model where the version is part of the port name, e.g. the 
>> current one would be 

Re: Review a fix for OpenSSL3 CVE

[grey]

I think neverpanic tends to be pretty responsive?

Moreover in the severity was downgraded from Critical to High between the
time the vulnerability was circulating through the grapevine until it
actually was disclosed. There are also no known exploits in the wild
thankfully.

LibreSSL (which is what macOS ships in base) is also not vulnerable,
neither is OpenSSL1.

Anyway, I agree it's important to get tested and merged, but I'm not sure
if it would be necessary to jump the gun of the maintainers?

On Tue, Nov 1, 2022, 11:04 Kirill A. Korinsky via macports-dev <
macports-dev@lists.macports.org> wrote:

> Folks,
>
> OpenSSL team released a fix for found CVE:
> https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/
>
> May I ask someone to review a PR to fix this CVE?
>
> https://github.com/macports/macports-ports/pull/16545
>
> I think that this CVE should be a reason to merge such PR ASAP without
> maintainers confirmation.
>
> --
> wbr, Kirill
>
>

Re: latest git version no longer detected by base

[grey]

I realize I am late chiming in on this thread, and this is, without
a doubt, almost entirely tangential. However, I created a preliminary
Portfile for got-portable (got [Gameoftrees] is a BSD licensed, git
compatible tool aiming for something similar to be a drop in
replacement for git, though it is currently still very much a work in
progress from some OpenBSD developers, not entirely dissimilar to for
example, openrsync as an rsync replacement/alternative.).

At the moment, I've only opened a Trac ticket, rather than submitted a
PR, as I am not entirely sure what the process is to submit a new
MacPort for approval even after having read and followed
https://guide.macports.org/chunked/development.creating-portfile.html.

The Trac ticket, with an attached Portfile for got-portable may be found here:
  https://trac.macports.org/ticket/65059

Note that in its present state it is probably not likely to be useful
for replacing git in every conceivable workflow, but if you wanted to
help test the Portfile and see if it might be useful in a situation
where you had previously used git, or at the very least if it seems
worth submitting as a MacPort, additional eyes and testing would be
appreciated!

To wit, though also tangential to the origins of the thread, FreeBSD
uses gitup (https://github.com/johnmehr/gitup) in base, which is sort
of similar to FreeBSD's earlier tools svnlite and csup (for Subversion
and CVS respectively) but as far as I know, gitup is intended more for
syncing from repositories rather than committing to them. In contrast,
I believe (though I may be mistaken) that got (GameOfTrees) has an
intention to be a more fully fledged git alternative (in ways that
perhaps fossil-scm's git compatibility failed to deliver on its
promise)? Nonetheless, it would probably be nice to have a MacPort of
FreeBSD's gitup as well, though last I checked, FreeBSD's gitup had a
name collision with this gitup, which is very different, but already
has a MacPort: https://ports.macports.org/port/GitUp/ Suffice to say,
that I tend to be a bit more familiar with OpenBSD's code branches
despite years of also running FreeBSD in production environments as
well, so for a first effort, got seemed as if it was something easier
for me to cut my teeth on with regards to submitting a Portfile for a
new port.

My apologies for adding any distractions to discourse related to the
mainline git client in this thread.



On Sun, Apr 17, 2022 at 2:16 AM Herby G  wrote:
>
> As I mentioned in my original comment on the commit, the big change in Git 
> 2.35.3 (and starting in 2.35.2) is a major behavior change to address 
> CVE-2022-24765
>
> What this means in practice is that Git will no longer operate on or process 
> any higher level Git directories with different ownership.
>
> As I had mentioned to Ken earlier on in this list, you can try setting the 
> safe.directory configuration value to disable this behavior as mentioned in 
> the above post: 
> https://git-scm.com/docs/git-config/2.35.2#Documentation/git-config.txt-safedirectory
>
> It looks like it should be safe.directory = * in the master git configuration 
> file, though I have not tried that myself.
>
>
> On Sat, Apr 16, 2022 at 11:13 AM Chris Jones  wrote:
>>
>>
>>
>> On 14 Apr 2022, at 11:16 pm, Joshua Root  wrote:
>>
>> On 2022-4-14 23:56 , Christopher Jones wrote:
>>
>> Hi All,
>>
>> Does anyone have any ideas on
>>
>> https://github.com/macports/macports-ports/commit/053dbb666a57972ceefba10b1edd12f16d886fd4#commitcomment-71271508
>>  
>> 
>>
>> something about the latest git port is causing it to no longer to properly 
>> detected and used by base..
>>
>>
>> The git used by port sync is whatever is found by macports::findBinary: 
>> 
>>
>> And that ends up calling binaryInPath, which simply looks for an executable 
>> file of the given name in each directory in PATH: 
>> 
>>
>> FWIW, my syncs still use /opt/local/bin/git after upgrading.
>>
>>
>> What OS is this ? For me the issue is happening on macOS 12.
>>
>> The problem is completely reproducible. I can uninstall macports git and it 
>> starts working again with the system binary, and then reinstall macports 
>> version and it stops working again..
>>
>> I think at some point I will have to probably just put some more verbose 
>> debug into base, to try and help figure out what exactly is happening there 
>> to cause it to fail to use macports git correctly.. my suspicion is its 
>> something to do with the checks performed at
>>
>> https://github.com/macports/macports-base/blob/5d637741b5ae04b63f7e99a9057c6764d29fd7fd/src/macports1.0/macports.tcl#L2613
>>
>> That are no longer working correctly for some reason, leading to a 

re: OpenSSH 8.9p1 deprecated variants cleanup feedback request

[grey]

Hello!

Somewhat recently, I submitted a PR for OpenSSH 8.9p1 to bring it
-current with the release on openssh.com, and it was merged, and all
seemed well with the world, or at least that port, ever so briefly. ;)

Not long after, via Trac, thetrial (alabay) indicated an error with
the +gsskex variant on OS X El Capitan, which I certainly hadn't
tested with my initial Portfile diff and merged PR. After a bit of
rummaging around for a laptop I could access which still had OS X El
Capitan installed, I determined that while the issue indicated was
reproducible, it had more to do with the +gsskex variant and
attempting to apply a patch for 8.8p1. In other words: the issue is
not constrained to El Capitan, it is instead related to the +gsskex
variant and a patch which no longer applies cleanly to the 8.9p1
codebase.

However, this is a patch (i.e. GSSAPI/gsskex) which has been rejected
from the upstream OpenSSH project, for over two decades now. The
wording in the patch itself is rather cautionary in nature with some
salient quotes from the OpenSSH developer community as far as why they
rejected it and I pasted that quote as an excerpt in the comments in
my next PR effort, which removed references to the patch, as well as
removed the patch itself from the files subdirectory for the OpenSSH
port.

That PR is here:
https://github.com/macports/macports-ports/pull/14193

Additionally, it appears as if the original author of the patch,
Simon Wilkinson, has also abandoned it, with
http://www.sxw.org.uk/computing/patches/ where it previously resided,
presently redirecting to what appears to be his Lighting and Design
career website?

Looking a little bit more deeply into this, aside from getting some
helpful suggestions from Herby (who also suggested I email this
mailing list, hence this message) I couldn't help but notice that
there are still various patches in the OpenSSH port files subdirectory
related to the no longer extant in the Portfile HPN variant, which
also appears to have been deprecated for quite some time? I know
FreeBSD's port also abandoned their HPN related OpenSSH patches some
years ago as well, though I admit I never paid close attention to that
variant with MacPorts to know its lifecycle.

In other words: the OpenSSH port has been without a maintainer, and
the Portfile and associated files subdirectory seem to have accrued
some bitrot.

While I can presumably amend my last PR or submit another PR with a
bit of additional housekeeping to remove the HPN related files for
example, in addition to my extant minimalist effort to simply
eliminate errors in the +gsskex variant (admittedly, without actually
removing references to it with the variant stanzas entirely from the
Portfile, which is probably a wiser decision along that line of
thought) it seems as if it might be worthwhile to bring some of these
issues to the attention of the larger MacPorts developer community for
perspective and hopefully helpful suggestions?

Maybe it is my nerves talking, but especially given that I do not have
commit access and am not the most facile with GitHub having only had
three PRs merged into MacPorts thus far; I don't feel as if I have a
lot of confidence in my actions as related to git presently (I'm an
older than CVS kind of coder, some newfangled Linuxisms rife tools
don't sit well with me). Moreover, maybe some people really liked the
+gsskex/GSSAPI patch for OpenSSH which is why they had refactored it
for 8.8p1? To me, the gsskex variant kind of screams: "yikes,
plausible attack surface" and like the deprecated HPN patches, it and
its associated references and files are worth jettisoning, but I do
not profess to be an authoritative source for any of that so much as I
am sharing my opinion.

What do others think? Feedback is welcome! I didn't mean to harsh on
Renee in the PR comments either, but Renee was pretty up front about
not actually using the OpenSSH port, so I would mostly appreciate
perspective from individuals who do actually use the OpenSSH port and
have some "skin in the game" as the idiomatic expression goes.

For the life of me, I can't really see much good coming from the
+gsskex/GSSAPI variant, but I also do not presently administer any
Kerberos related infrastructure at the moment (thankfully, if slightly
tangentially, I also do not administer any yp related infrastructure
these days anymore and can blissfully only recall them and their
associated security holes with ypcat abuses as distant early 1990s
memories now).

Thank you in advance for any wisdom you may be able to share on this issue!

｜
グ
レ
ェ
ーgrey

p.s. Happy π day!