Re: keychain exporter/ing code?

[René J . V . Bertin]

On Wednesday June 07 2023 06:55:25 Sriranga Veeraraghavan wrote:

Hi,


>I haven't tried it, but there is a 'dump-keychain' command for security(1) 
>that might do what you want:


Yes, that's why I know I could use the code from the source for that command. 
The format as it is is quite useless though, sadly.

Re: keychain exporter/ing code?

[Sriranga Veeraraghavan]

Hi,

I haven't tried it, but there is a 'dump-keychain' command for security(1) that 
might do what you want:

security dump-keychain -d [keychain] > keychain.txt

Where [keychain] is the name of the keychain you want export (for example 
'login.keychain').

Best,

-ranga

> On Jun 7, 2023, at 06:22, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I'm looking for some code that will allow me to export the entire contents of 
> Apple keychains, if possible directly in a way that I can import the data in 
> another cross-platform utility.
> I should be able to write something based on the "security" (example?) tool 
> but would of course prefer to use an already tested library.
> 
> Any suggestions?
> 
> Thanks,
> René

keychain exporter/ing code?

[René J . V . Bertin]

Hi,

I'm looking for some code that will allow me to export the entire contents of 
Apple keychains, if possible directly in a way that I can import the data in 
another cross-platform utility.
I should be able to write something based on the "security" (example?) tool but 
would of course prefer to use an already tested library.

Any suggestions?

Thanks,
René

Re: Portfile question for 10.6.8

[raf via macports-users]

On Tue, Jun 06, 2023 at 06:45:58PM -0700, Ken Cunningham 
 wrote:

> > On Jun 6, 2023, at 6:16 PM, raf via macports-users 
> >  wrote:
> > 
> > On Wed, Jun 07, 2023 at 11:09:13AM +1000, raf via macports-users 
> >  wrote:
> > 
> >> So if I use different macro names (e.g. ALL_CFLAGS and ALL_LDFLAGS), and 
> >> just
> >> add $(CFLAGS) and $(LDFLAGS) from the environment to it, then it should 
> >> work.
> >> I'll try that.
> >> 
> >> Yay! It worked. Many thanks. I'll fix my Makefile for the upcoming version
> >> of rawhide and create the Portfile for that.
> > 
> > That still leaves the question of how 10.6.8 hosts can download distfiles
> > from a non-https site (when https sites won't support TLS 1.0). Do distfiles
> > magically end up on http://distfiles.macports.org?
> > 
> > cheers,
> > raf
> 
> Newer systems download them to distfiles.macports.org
> , and that site supports older TLS so
> older systems can get them from there.

Thanks.

cheers,
raf

Re: Portfile question for 10.6.8

[raf via macports-users]

On Tue, Jun 06, 2023 at 06:49:35PM -0700, Ken Cunningham 
 wrote:

> > On Jun 6, 2023, at 6:28 PM, raf via macports-users 
> >  wrote:
> > 
> > On Wed, Jun 07, 2023 at 11:09:13AM +1000, raf via macports-users 
> >  wrote:
> > 
> >> Yay! It worked. Many thanks. I'll fix my Makefile for the upcoming version
> >> of rawhide and create the Portfile for that.
> > 
> > I spoke too soon. The compilation worked, but when I ran the
> > program to list everything in my home directory, there were
> > many many "Bad file descriptor" errors for fstatat(). It's
> > happening for everything immediately below the current
> > directory. Any ideas?
> > 
> > cheers,
> > raf
> 
> is  -I/opt/local/include/LegacySupport making it into your CFLAGS and 
> CXXFLAGS during the build?

It is now.

  CFLAGS='-Os -I/opt/local/include/LegacySupport -arch x86_64'
  LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names 
-lMacportsLegacySupport -arch x86_64'

An example compilation command is:

  cc -Os -I/opt/local/include/LegacySupport -arch
  x86_64 -O3 -g -Wall -pedantic -DETCDIR=\"/etc\"
  -DRAWHIDE_NAME=\"rawhide\" -DRAWHIDE_PROG_NAME=\"rh\"
  -DRAWHIDE_VERSION=\"3.1\" -DRAWHIDE_DATE=\"20221011\"
  -DHAVE_PCRE2=1 -DHAVE_ACL=1 -DHAVE_POSIX_ACL=1
  -DHAVE_MACOS_ACL=1 -DHAVE_EA=1 -DHAVE_MACOS_EA=1
  -DHAVE_FLAGS=1 -DHAVE_MAGIC=1-I/opt/local/include
  -c rhdir.c

And the final link command is:

  cc -Os -I/opt/local/include/LegacySupport -arch
  x86_64 -O3 -g -Wall -pedantic -DETCDIR=\"/etc\"
  -DRAWHIDE_NAME=\"rawhide\" -DRAWHIDE_PROG_NAME=\"rh\"
  -DRAWHIDE_VERSION=\"3.1\" -DRAWHIDE_DATE=\"20221011\"
  -DHAVE_PCRE2=1 -DHAVE_ACL=1 -DHAVE_POSIX_ACL=1
  -DHAVE_MACOS_ACL=1 -DHAVE_EA=1 -DHAVE_MACOS_EA=1
  -DHAVE_FLAGS=1 -DHAVE_MAGIC=1-I/opt/local/include
  -o rh rhcmds.o rh.o rhparse.o rhdir.o rhdata.o
  rhstr.o rherr.o -L/opt/local/lib
  -Wl,-headerpad_max_install_names
  -lMacportsLegacySupport -arch x86_64 -L/opt/local/lib
  -lpcre2-8 -lmagic

And with debugging on, everything looks correct until
the error:

  openat(parent_fd=3, path=.git)
  openat: dir_fd 4
  fdopendir(dir_fd=4)
  dir entry ./.git/branches
  fstatat(parent_fd=4, path=branches)
  rh: fstatat ./.git/branches: Bad file descriptor

The "bad" file descriptor is 4 which was returned by openat.
That what's it looks like on other systems that work. Mysterious.

cheers,
raf