-
Notifications
You must be signed in to change notification settings - Fork 23
Adding Arch Support #25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Would the intention of this be that there would be a bash script for each distro? I use Debian and was looking into the script myself to see if it will run on my setup. Did you notice any issues with the script since Debian uses firefox-esr? I'm looking into it now and wondering if that name difference would cause any issues. I also see you made your changes off of main. I saw in the development branch that there was some effort made to support opensc as opposed to cackey I think. There might be value in considering if you should add that to this PR. Other people more familiar with the project might have better thoughts on that. |
I'd like to create one monolithic script. Perhaps distro-specific functions would be worth considering. The separate scripts are just in case you want to take development in another direction. I'm happy to keep collaborating until we have something more robust and mature. I know the method used to get the CAC working properly is compatible with Firefox-esr (I have another machine where we did this by hand). But I didn't try on a vanilla Debian distro. Another issue worth considering is Ubuntu (which is Debian-based), which now uses a snap to install Firefox, which I've been unsuccessful at getting the CAC working. I had to uninstall the snap version and install it again from the official Mozilla repo. So, if we want this script to be more versatile, we must understand the environment more fully. Regarding OpenSC, I had trouble getting cackey to work on Arch. I didn't try too hard and found this to be a workaround. Here's how I see this project possibly progressing. Our main script first checks our distribution and how the browsers are installed first. Based on that, we import distro-specific helper functions. These helper function files generally have the same named functions but are only included by the main function using that filer. So the project hierarchy looks something similar to this ├── cac_setup.sh
└── helper
├── arch_helper.sh
├── debian_helper.sh
└── global_helper.sh where #!/bin/bash
# Capture script directory path
DIR="$( cd "$( dirname "${BASH_SOURCE[0]-$0}" )" && pwd )"
# Source universal helper functions
source $DIR/helper/global_helper.sh
# Determine the Linux distribution by checking the release information
if grep -qi "Debian" /etc/os-release; then
# Source the Debian-specific helper script if Debian is detected
source $DIR/helper/debian_helper.sh
elif grep -qi "Arch" /etc/os-release; then
# Source the Arch-specific helper script if Arch Linux is detected
source $DIR/helper/arch_helper.sh
else
echo "Unsupported Linux distribution."
fi
# Continue installation This way, we can make the same calls in the main script while ensuring distro-specific support. Thoughts? |
The script should work fine with Ubuntu. It was our main testing
environment when we originally developed the script. When Unbuntu moved to
Snap, we added in the option to try to uninstall the snap version and force
the apt version (by way of a new repo added to apt) then reinstall the apt
version. I even built in profile migration and re-adding the FF icon to the
dock.
When you ran the script on the machine which was unsuccessful, did it
prompt for you to choose whether or not to attempt the swap from snap to
apt?
…On Sat, Apr 20, 2024, 12:10 Derrek Landauer ***@***.***> wrote:
I'd like to create one monolithic script. Perhaps distro-specific
functions would be worth considering. The separate scripts are just in case
you want to take development in another direction. I'm happy to keep
collaborating until we have something more robust and mature.
I know the method used to get the CAC working properly is compatible with
Firefox-esr (I have another machine where we did this by hand). But I doubt
this script works out of the box for that configuration. Another issue
worth considering is Ubuntu (which is Debian-based), which now uses a snap
to install Firefox, which I've been unsuccessful at getting the CAC
working. So, if we want this script to be more versatile, we need to
understand the environment in which we're working better.
—
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGLSFW652TQ4KH5W3GUMIH3Y6KHO7AVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXG4YTQMJTGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Nothing like that I can recall. The scripts just powered through. Something may have changed with how Debian uses snap. if snap list | grep -q "^firefox"; then
snap_ff=true
print_err "This version of Firefox was installed as a snap package."
fi I don't use Debian/Ubuntu or snap, but maybe the above will work? |
Backing up the user's FF profile is done in The check for FF pinned to the dock is done on |
|
Yeah, I noticed all that. I can only speculate why the script wasn't firing off the expected logic on my intern's laptop. After some digging into forums, I figured out Snap doesn't like to allow users to add security devices. So, we proceeded with that updated knowledge. I'm fairly sure it was just Ubuntu, too, but it's possible it was PopOS. |
I use Pop_OS as my daily driver and I haven't had any issues with it so
far, knock on wood. Jeremy tested everything in regular Ubuntu and I tested
it in Pop.
We can track down the issue if you would be able to repeat the process on
your coworker's machine, taking note of all messages presented to you so we
can see the flow of logic.
I don't believe System76 are fans of snap, and don't use it for package
management. So you probably didn't get a prompt asking to replace FF
because it wasn't installed via snap.
…On Sat, Apr 20, 2024, 16:10 Derrek Landauer ***@***.***> wrote:
Yeah, I noticed all that. I can only speculate why the script wasn't
firing off the expected logic on my intern's laptop. After some digging
into forums, I figured out Snap doesn't like to allow users to add security
devices. So, we proceeded with that updated knowledge. I'm fairly sure it
was just Ubuntu, too, but it's possible it was PopOS.
—
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGLSFW423ZJEIWVWAGC3K4LY6LDR5AVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXG43TANBZGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yeah it's a System76 machine running ubuntu instead of Pop OS. I'll ask him next week to replay the script and see what happens... but I might need to do it in a virtual machine instead. I'll let you know if I learn more. |
I think you already know this, but just in case you didn't, so we're all on
the same page, System 76 computers come with Pop_OS installed by default
because it's their proprietary flavor of Ubuntu. Though while it's Ubuntu
based, it doesn't use snap, which Ubuntu started doing a couple of major
versions ago.
If it's still running Pop_OS, you won't see the prompt about removing the
snap version of Firefox, because Pop_OS doesn't have snap.
If the machine is actually running Ubuntu, you should be prompted during
running of the script, to remove the snap version of Firefox and replace it
with the apt version automatically.
…On Sat, Apr 20, 2024, 16:41 Derrek Landauer ***@***.***> wrote:
Yeah it's a System76 machine running ubuntu instead of Pop OS. I'll ask
him next week to replay the script and see what happens... but I might need
to do it in a virtual machine instead. I'll let you know if I learn more.
—
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGLSFWZTQBIRRCQIQKAFY5LY6LHHXAVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXG43TMNZQGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
When configuring the specs of your System76 machine you can select to have Ubuntu installed at the factory. My intern's machine is one such laptop. |
integration common functions and separation of distro specfic tasks.
@Derrekito, I appreciate all of your contributions! I'm going to try to cover most of the major issues that have been mentioned in this thread. As Ben previously mentioned, the original script was designed to handle the nuance of snap within Ubuntu. Recently, I ran the script on a VM with a fresh install of Ubuntu 22.04, and it did not behave as expected. I'm afraid there is some logical error in the control flow while checking for browsers. Dealing with Snap only complicates this more. I am not a fan of how Canonical makes Snap hijack the install from apt by default. The user has to take additional steps to force the installation to behave as expected when attempting to reinstall Firefox with apt. The production version of the script that rests in In my spare time, I have been working to refactor, simplify the process, and transition to OpenSC with help from @malvidin's contributions. Currently, the OpenSC implementation is functional but requires a reboot. While trivial, I don't think a reboot should be necessary, but when running On a separate note, I like the modularity of the individual files that you have implemented so far. That being said, I have kept the script monolithic to keep the footprint minimal. That's the same reason I have kept the script as Bash. I have often debated transitioning to either Ansible or Python. In the project's readme, you'll see the simplified methods for running the script: I am also attempting to implement some CI with the automated |
@Derrekito, I reconfigured the |
Added a -x flag to the shellcheck call.
Trying a different method to run shellcheck with -x option.
I understand your point. I'm happy to try and contribute in other ways if needed. Just keep me in mind. I like the idea of running the script using one line using bash and wget. It would make things simpler. Perhaps one monolithic script is maintainable. I like to go nuts when making bash functions. It helps me understand what my script is doing a year down the road. Maybe we can have distro-specific functions with a trailing |
I like the idea of a monolithic script with distro specific functions, but
only at the lowest possible level for each distro. That is to say: if the
process for Distro_A and Distro_B are nearly identical over the course of a
500 line script with the exception of lines 202-208 and 411-423, those two
sections of code with get distro specific functions, and the remainder of
the script would not need to be duplicated.
I also really strived to keep the whole "You're FF is crappy snap, do you
want to fix that?" Section as simple and user-friendly, guided, if you
will, as much as possible. The more of the heavy lifting the script can do
for the end user, the more valuable it becomes.
…On Fri, Apr 26, 2024, 15:18 Derrek Landauer ***@***.***> wrote:
I'd like to create one monolithic script. Perhaps distro-specific
functions would be worth considering. The separate scripts are just in case
you want to take development in another direction. I'm happy to keep
collaborating until we have something more robust and mature.
I know the method used to get the CAC working properly is compatible with
Firefox-esr (I have another machine where we did this by hand). But I
didn't try on a vanilla Debian distro. Another issue worth considering is
Ubuntu (which is Debian-based), which now uses a snap to install Firefox,
which I've been unsuccessful at getting the CAC working. I had to uninstall
the snap version and install it again from the official Mozilla repo. So,
if we want this script to be more versatile, we must understand the
environment more fully.
Regarding OpenSC, I had trouble getting cackey to work on Arch. I didn't
try too hard and found this to be a workaround.
Here's how I see this project possibly progressing.
Our main script first checks our distribution and how the browsers are
installed first. Based on that, we import distro-specific helper functions.
These helper function files generally have the same named functions but are
only included by the main function using that filer.
So the project hierarchy looks something similar to this
├── cac_setup.sh
└── helper
├── arch_helper.sh
├── debian_helper.sh
└── global_helper.sh
where cac_setup.sh begins with something like
#!/bin/bash
# Capture script directory path
DIR="$( cd "$( dirname "${BASH_SOURCE[0]-$0}" )" && pwd )"
# Source universal helper functionssource $DIR/helper/global_helper.sh
# Determine the Linux distribution by checking the release informationif grep -qi "Debian" /etc/os-release; then
# Source the Debian-specific helper script if Debian is detected
source $DIR/helper/debian_helper.shelif grep -qi "Arch" /etc/os-release; then
# Source the Arch-specific helper script if Arch Linux is detected
source $DIR/helper/arch_helper.shelse
echo "Unsupported Linux distribution."fi
# Continue installation
This way, we can make the same calls in the main script while ensuring
distro-specific support.
Thoughts?
@Derrekito <https://github.com/Derrekito>, I appreciate all of your
contributions! I'm going to try to cover most of the major issues that have
been mentioned in this thread.
As Ben previously mentioned, the original script was designed to handle
the nuance of snap within Ubuntu. Recently, I ran the script on a VM with a
fresh install of Ubuntu 22.04, and it did not behave as expected. I'm
afraid there is some logical error in the control flow while checking for
browsers. Dealing with Snap only complicates this more. I am not a fan of
how Canonical makes Snap hijack the install from apt by default. The user
has to take additional steps to *force* the installation to behave as
expected when attempting to reinstall Firefox with apt. The production
version of the script that rests in main was built to handle all of these
issues.
In my spare time, I have been working to refactor, simplify the process,
and transition to OpenSC with help from @malvidin
<https://github.com/malvidin>'s contributions. Currently, the OpenSC
implementation is functional but requires a reboot. While trivial, I don't
think a reboot should be necessary, but when running pkcs11-register in
the script, it doesn't want to write to the PKCS files as expected and
still requires a reboot.
On a separate note, I like the modularity of the individual files that you
have implemented so far. That being said, I have kept the script monolithic
to keep the footprint minimal. That's the same reason I have kept the
script as Bash. I have often debated transitioning to either Ansible or
Python. In the project's readme, you'll see the simplified methods for
running the script: sudo bash -c "$(wget
https://raw.githubusercontent.com/jdjaxon/linux_cac/main/cac_setup.sh -O
-)". The intent of this is to prevent the user from having to clone the
repository. Using any of those methods doesn't even copy the base script to
the host machine. The only components that generate any footprint are the
dependencies to run a CAC (middleware), downloading dependencies (wget),
and any writing to config files. If I ignore this footprint issue, shifting
to Python or Ansible is a much more modular and extensible approach.
I am also attempting to implement some CI with the automated shellcheck
workflow. I am open to any suggestions you have for improving the project,
such as minimizing the footprint, ignoring the footprint while increasing
functionality, modularity, and extensibility, or additional automated
testing.
I understand your point. I'm happy to try and contribute in other ways if
needed. Just keep me in mind. I like the idea of running the script using
one line using bash and wget. It would make things simpler. Perhaps one
monolithic script is maintainable. I like to go nuts when making bash
functions. It helps me understand what my script is doing a year down the
road. Maybe we can have distro-specific functions with a trailing _deb or
_arch and build in the logic to know which to execute. Or the main
function calls something like build_for_deb and build_for_arch` (I'm
terrible at naming things), and those functions somewhat duplicate the
install process but call the distro-specific functions. Lots of ways to go
about this.
—
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGLSFW3D5NMQAUFE5ZE7C7DY7KSBVAVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZZHE4DSNBRGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@bengooch7 @jdjaxon @Derrekito any updates on getting this merged? I daily drive Arch (btw) and would like to have a simple script like this instead of manually configuring everything. I tried running the script and this was the output:
The cert imports fail because the cert URL is messed up. I fixed that locally, and then everything seems to work correctly. Thank you all for your hard work maintaining the best way to set all this up on Linux! |
@Derrekito, my apologies for dropping the ball here. I think the way forward for this is to keep the script as one monolithic file. If you want to drop the additional files, resolve any conflicts, and ensure the tests pass, we can try to get this merged. Respond here if you run into any conflict you don't know how to resolve. The conflicts will likely be the changes from cackey to opensc. Maybe a few others. Do you have a way to test this on a distro other than Arch so we can guarantee that there is no regression? I have some other portability issues that I need to fix as well, but I can tackle those after we merge your work. |
Hate to pull anyone away from this repo, but I've redone the scripts to
also use more up-to-date middleware software which supports the Microsoft
login process with a CAC better.
https://github.com/Derrekito/linux-cac-setup
I've used the arch script on several of my arch machines and my interns
have been successful with the popOS version (which should work with Ubuntu
too). I haven't had the bandwidth to spend too much time on it, but always
happy to support if needed.
…On Mon, Jun 9, 2025, 09:33 Dale Lakes ***@***.***> wrote:
*spitfire55* left a comment (jdjaxon/linux_cac#25)
<#25 (comment)>
@bengooch7 <https://github.com/bengooch7> @jdjaxon
<https://github.com/jdjaxon> @Derrekito <https://github.com/Derrekito>
any updates on getting this merged? I daily drive Arch (btw) and would like
to have a simple script like this instead of manually configuring
everything. I tried running the script and this was the output:
❯ sudo ./cac_setup.sh
[sudo] password for dlakes:
Arch Linux detected.
[INFO] Checking for Firefox and Chrome...
[INFO] Firefox not found.
[INFO] Found Google Chrome.
[INFO] Installing middleware...
:: Synchronizing package databases...
endeavouros is up to date
core is up to date
extra is up to date
multilib is up to date
warning: ccid-1.6.2-1 is up to date -- reinstalling
warning: opensc-0.26.1-1 is up to date -- reinstalling
warning: pcsc-tools-1.7.3-1 is up to date -- reinstalling
warning: nss-3.112-1 is up to date -- reinstalling
warning: unzip-6.0-22 is up to date -- reinstalling
warning: wget-1.25.0-2 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Package (6) Old Version New Version Net Change
extra/ccid 1.6.2-1 1.6.2-1 0.00 MiB
core/nss 3.112-1 3.112-1 0.00 MiB
extra/opensc 0.26.1-1 0.26.1-1 0.00 MiB
extra/pcsc-tools 1.7.3-1 1.7.3-1 0.00 MiB
extra/unzip 6.0-22 6.0-22 0.00 MiB
extra/wget 1.25.0-2 1.25.0-2 0.00 MiB
Total Installed Size: 13.43 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n]
(6/6) checking keys in keyring [--------------------------------------] 100%
(6/6) checking package integrity [--------------------------------------] 100%
(6/6) loading package files [--------------------------------------] 100%
(6/6) checking for file conflicts [--------------------------------------] 100%
:: Processing package changes...
(1/6) reinstalling ccid [--------------------------------------] 100%
(2/6) reinstalling opensc [--------------------------------------] 100%
(3/6) reinstalling pcsc-tools [--------------------------------------] 100%
(4/6) reinstalling nss [--------------------------------------] 100%
(5/6) reinstalling unzip [--------------------------------------] 100%
(6/6) reinstalling wget [--------------------------------------] 100%
:: Running post-transaction hooks...
(1/5) Reloading device manager configuration...
(2/5) Arming ConditionNeedsUpdate...
(3/5) Checking which packages need to be rebuilt
(4/5) Updating the info directory file...
(5/5) Updating the desktop file MIME type cache...
[INFO] Done
[INFO] Downloading DoD certificates and Cackey package...
[INFO] Done.
[INFO] Installing libcackey using yay...
AUR Explicit (1): cackey-0.7.11-1
:: PKGBUILD up to date, skipping download: cackey
1 cackey (Installed) (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
1 cackey (Installed) (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
==> Making package: cackey 0.7.11-1 (Mon 09 Jun 2025 11:24:30 AM EDT)
==> Retrieving sources...
-> Found cackey-0.7.11.tar.gz
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
cackey-0.7.11.tar.gz ... Passed
:: (1/1) Parsing SRCINFO: cackey
==> Making package: cackey 0.7.11-1 (Mon 09 Jun 2025 11:24:31 AM EDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found cackey-0.7.11.tar.gz
==> Validating source files with sha256sums...
cackey-0.7.11.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Extracting cackey-0.7.11.tar.gz with bsdtar
==> Sources are ready.
-> cackey-0.7.11-1 already made -- skipping build
==> Making package: cackey 0.7.11-1 (Mon 09 Jun 2025 11:24:34 AM EDT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Sources are ready.
[sudo] password for dlakes:
loading packages...
warning: cackey-0.7.11-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Package (1) Old Version New Version Net Change
cackey 0.7.11-1 0.7.11-1 0.00 MiB
Total Installed Size: 0.43 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [--------------------------------------] 100%
(1/1) checking package integrity [--------------------------------------] 100%
(1/1) loading package files [--------------------------------------] 100%
(1/1) checking for file conflicts [--------------------------------------] 100%
:: Processing package changes...
(1/1) reinstalling cackey [--------------------------------------] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Checking which packages need to be rebuilt
[INFO] libcackey.so found at /usr/lib/libcackey.so
[INFO] Importing certificates for Chrome...
[INFO] Loading certificates into /home/dlakes/.pki/nssdb
Importing /tmp/AllCerts/*.cer
certutil: unable to open "/tmp/AllCerts/*.cer" for reading (-5950, 2).
Done.
[INFO] Importing certificates for Firefox...
[INFO] Loading certificates into /home/dlakes/.mozilla/firefox/v9lmwr4t.dev-edition-default
Importing /tmp/AllCerts/*.cer
certutil: unable to open "/tmp/AllCerts/*.cer" for reading (-5950, 2).
Done.
[INFO] Enabling pcscd service to start on boot...
[INFO] Removing artifacts...
[INFO] Done.
The cert imports fail because the cert URL is messed up. I fixed that
locally, and then everything seems to work correctly.
Thank you all for your hard work maintaining the best way to set all this
up on Linux!
—
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFS5SZ2QF2MPWIL7KY6VGL3CWSLZAVCNFSM6AAAAAB65HTD7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJWGE2DQNRZG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Understood. I appreciate the fast response. Are you referring to OpenSC? If so, we've migrated to that as well. CACKey was a bit too unstable for my taste. |
Correct! Only issue I've come across with the update is the Linux login
process glitching out if the CAC is insert upon boot. It wants to use the
credentials from the card, which may not map to a system user.
…On Mon, Jun 9, 2025, 22:20 Jeremy Jackson ***@***.***> wrote:
*jdjaxon* left a comment (jdjaxon/linux_cac#25)
<#25 (comment)>
Hate to pull anyone away from this repo, but I've redone the scripts to
also use more up-to-date middleware software which supports the Microsoft
login process with a CAC better.
https://github.com/Derrekito/linux-cac-setup I've used the arch script on
several of my arch machines and my interns have been successful with the
popOS version (which should work with Ubuntu too). I haven't had the
bandwidth to spend too much time on it, but always happy to support if
needed.
… <#m_9171866540512192332_>
On Mon, Jun 9, 2025, 09:33 Dale Lakes *@*.*> wrote: spitfire55 left a
comment (jdjaxon/linux_cac#25
<#25>) <#25 (comment)
<#25 (comment)>>
@bengooch7 <https://github.com/bengooch7> https://github.com/bengooch7
<https://github.com/bengooch7> @jdjaxon <https://github.com/jdjaxon>
https://github.com/jdjaxon <https://github.com/jdjaxon> @Derrekito
<https://github.com/Derrekito> https://github.com/Derrekito
<https://github.com/Derrekito> any updates on getting this merged? I daily
drive Arch (btw) and would like to have a simple script like this instead
of manually configuring everything. I tried running the script and this was
the output: ❯ sudo ./cac_setup.sh [sudo] password for dlakes: Arch Linux
detected. [INFO] Checking for Firefox and Chrome... [INFO] Firefox not
found. [INFO] Found Google Chrome. [INFO] Installing middleware... ::
Synchronizing package databases... endeavouros is up to date core is up to
date extra is up to date multilib is up to date warning: ccid-1.6.2-1 is up
to date -- reinstalling warning: opensc-0.26.1-1 is up to date --
reinstalling warning: pcsc-tools-1.7.3-1 is up to date -- reinstalling
warning: nss-3.112-1 is up to date -- reinstalling warning: unzip-6.0-22 is
up to date -- reinstalling warning: wget-1.25.0-2 is up to date --
reinstalling resolving dependencies... looking for conflicting packages...
Package (6) Old Version New Version Net Change extra/ccid 1.6.2-1 1.6.2-1
0.00 MiB core/nss 3.112-1 3.112-1 0.00 MiB extra/opensc 0.26.1-1 0.26.1-1
0.00 MiB extra/pcsc-tools 1.7.3-1 1.7.3-1 0.00 MiB extra/unzip 6.0-22
6.0-22 0.00 MiB extra/wget 1.25.0-2 1.25.0-2 0.00 MiB Total Installed Size:
13.43 MiB Net Upgrade Size: 0.00 MiB :: Proceed with installation? [Y/n]
(6/6) checking keys in keyring [--------------------------------------]
100% (6/6) checking package integrity
[--------------------------------------] 100% (6/6) loading package files
[--------------------------------------] 100% (6/6) checking for file
conflicts [--------------------------------------] 100% :: Processing
package changes... (1/6) reinstalling ccid
[--------------------------------------] 100% (2/6) reinstalling opensc
[--------------------------------------] 100% (3/6) reinstalling pcsc-tools
[--------------------------------------] 100% (4/6) reinstalling nss
[--------------------------------------] 100% (5/6) reinstalling unzip
[--------------------------------------] 100% (6/6) reinstalling wget
[--------------------------------------] 100% :: Running post-transaction
hooks... (1/5) Reloading device manager configuration... (2/5) Arming
ConditionNeedsUpdate... (3/5) Checking which packages need to be rebuilt
(4/5) Updating the info directory file... (5/5) Updating the desktop file
MIME type cache... [INFO] Done [INFO] Downloading DoD certificates and
Cackey package... [INFO] Done. [INFO] Installing libcackey using yay... AUR
Explicit (1): cackey-0.7.11-1 :: PKGBUILD up to date, skipping download:
cackey 1 cackey (Installed) (Build Files Exist) ==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4) ==>
1 cackey (Installed) (Build Files Exist) ==> Diffs to show? ==> [N]one
[A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4) ==> ==> Making
package: cackey 0.7.11-1 (Mon 09 Jun 2025 11:24:30 AM EDT) ==> Retrieving
sources... -> Found cackey-0.7.11.tar.gz ==> WARNING: Skipping verification
of source file PGP signatures. ==> Validating source files with
sha256sums... cackey-0.7.11.tar.gz ... Passed :: (1/1) Parsing SRCINFO:
cackey ==> Making package: cackey 0.7.11-1 (Mon 09 Jun 2025 11:24:31 AM
EDT) ==> Checking runtime dependencies... ==> Checking buildtime
dependencies... ==> Retrieving sources... -> Found cackey-0.7.11.tar.gz ==>
Validating source files with sha256sums... cackey-0.7.11.tar.gz ... Passed
==> Removing existing $srcdir/ directory... ==> Extracting sources... ->
Extracting cackey-0.7.11.tar.gz with bsdtar ==> Sources are ready. ->
cackey-0.7.11-1 already made -- skipping build ==> Making package: cackey
0.7.11-1 (Mon 09 Jun 2025 11:24:34 AM EDT) ==> Checking runtime
dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using
existing $srcdir/ tree ==> Sources are ready. [sudo] password for dlakes:
loading packages... warning: cackey-0.7.11-1 is up to date -- reinstalling
resolving dependencies... looking for conflicting packages... Package (1)
Old Version New Version Net Change cackey 0.7.11-1 0.7.11-1 0.00 MiB Total
Installed Size: 0.43 MiB Net Upgrade Size: 0.00 MiB :: Proceed with
installation? [Y/n] (1/1) checking keys in keyring
[--------------------------------------] 100% (1/1) checking package
integrity [--------------------------------------] 100% (1/1) loading
package files [--------------------------------------] 100% (1/1) checking
for file conflicts [--------------------------------------] 100% ::
Processing package changes... (1/1) reinstalling cackey
[--------------------------------------] 100% :: Running post-transaction
hooks... (1/2) Arming ConditionNeedsUpdate... (2/2) Checking which packages
need to be rebuilt [INFO] libcackey.so found at /usr/lib/libcackey.so
[INFO] Importing certificates for Chrome... [INFO] Loading certificates
into /home/dlakes/.pki/nssdb Importing /tmp/AllCerts/.cer certutil: unable
to open "/tmp/AllCerts/.cer" for reading (-5950, 2). Done. [INFO] Importing
certificates for Firefox... [INFO] Loading certificates into
/home/dlakes/.mozilla/firefox/v9lmwr4t.dev-edition-default Importing
/tmp/AllCerts/*.cer certutil: unable to open "/tmp/AllCerts/*.cer" for
reading (-5950, 2). Done. [INFO] Enabling pcscd service to start on boot...
[INFO] Removing artifacts... [INFO] Done. The cert imports fail because the
cert URL is messed up. I fixed that locally, and then everything seems to
work correctly. Thank you all for your hard work maintaining the best way
to set all this up on Linux! — Reply to this email directly, view it on
GitHub <#25 (comment)
<#25 (comment)>>, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFS5SZ2QF2MPWIL7KY6VGL3CWSLZAVCNFSM6AAAAAB65HTD7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJWGE2DQNRZG4
<https://github.com/notifications/unsubscribe-auth/AAFS5SZ2QF2MPWIL7KY6VGL3CWSLZAVCNFSM6AAAAAB65HTD7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJWGE2DQNRZG4>
. You are receiving this because you were mentioned.Message ID: @.***>
Understood. I appreciate the fast response. Are you referring to OpenSC.
If so, we've migrated to that as well. CACKey was a bit too unstable for my
taste.
—
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFS5S6SR7KK7YYQGJYQ3PD3CZMIFAVCNFSM6AAAAAB65HTD7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJXGYZTCNZTGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I have the same issue. I would prefer you have the credit for the Arch contributions here since you did the work. Are you no longer interested? |
I'm interested 🙂. Sorry, I might have misread some of our prior correspondences. I'll look into a pull request if I get some time tomorrow. |
If you have any concerns or would like to discuss anything, feel free to
message me directly on linkedin. You can find my profile on my home github
page.
Respectfully,
Jeremy Jackson
…On Tue, Jun 10, 2025, 00:40 Derrek Landauer ***@***.***> wrote:
*Derrekito* left a comment (jdjaxon/linux_cac#25)
<#25 (comment)>
@Derrekito <https://github.com/Derrekito>
I have the same issue.
I would prefer you have the credit for the Arch contributions here since
you did the work. Are you no longer interested?
I'm interested 🙂. Sorry, I might have misread some of our prior
correspondences. I'll look into a pull request if I get some time tomorrow.
—
Reply to this email directly, view it on GitHub
<#25 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU57KXRR64DB7JH3NIZOEKL3CZOSTAVCNFSM6AAAAAB65HTD7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJXGY2TMMJWGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I don't think this is quite ready and I'm looking for feedback. If we come to an agreement I'll remove the extraneous files and squash the commits so it won't pollute the history.