Package Details: sfdx-cli 7.150.0-1

Git Clone URL: (read-only, click to copy)
Package Base: sfdx-cli
Description: a tool for creating and managing Salesforce DX projects from the command line
Upstream URL:
Keywords: salesforce sfdx
Licenses: unknown
Provides: sfdx-cli
Submitter: dangmai
Maintainer: dangmai
Last Packager: dangmai
Votes: 3
Popularity: 0.002880
First Submitted: 2017-11-22 22:35 (UTC)
Last Updated: 2022-05-13 02:53 (UTC)

Pinned Comments

dangmai commented on 2019-04-01 03:19 (UTC)

Salesforce is no longer distributing the i686 version of this package, so I'm taking that version off of AUR. The only supported version now is x86_64 for this package. They also distribute an ARM version but I'm not sure if anyone would use it; if it's beneficial for you please put a comment here and I'll support that version as well.

Latest Comments

dangmai commented on 2022-02-04 16:38 (UTC)

I'm glad you figured out the issue, although I do see a material difference in the extracted file (from the .tar.gz) size. Unfortunately there's nothing I can do about it because it's distributed directly from Salesforce :(

dangmai commented on 2022-02-04 16:37 (UTC)

Good news is that it's not from my packaging process, bad news is that the ballooning size is from the package itself. I'm pulling the distributable directly from Salesforce (then repackaging it for AUR), and it looks like they're packing more and more static dependencies within the distributable, which I can't really do anything about.

Basically this package is a giant NodeJS project, and the majority of its size comes from the bundled node_modules.

duhdugg commented on 2022-02-04 16:23 (UTC)

(facepalm) OK, there's clearly something wrong with my AUR update workflow. I just rebuilt using a freshly cloned directory and the installed size is now 286.61 MB. I think the problem is that I wasn't clearing my src and/or pkg directories between builds. Sorry to bother you.

duhdugg commented on 2022-02-04 16:03 (UTC)

@dangmai the gist is just listing the tar file size, but they are consistent with what I'm seeing when pacman tells me the "Net Upgrade Size" when installing.

Right now, pacman -Qi sfdx-cli shows "Installed Size : 989.26 MiB".

dangmai commented on 2022-02-04 15:33 (UTC)

@duhdugg could I ask how you calculate those file sizes please? Is it from looking at the actual disk space used, or just looking at the tar file size?

dangmai commented on 2022-02-04 15:28 (UTC)

@duhdugg I'm taking a look, thank you for pointing that out. It may be a bug in my packaging process, but I need to do a deep dive

duhdugg commented on 2022-02-04 15:12 (UTC)

I'm noticing this package is making giant leaps in filesize with each update. Does anyone know why?

dangmai commented on 2021-10-15 14:00 (UTC)

I've updated the package to include the sf executable in user's PATH. Thanks again for letting me know about it.

dangmai commented on 2021-10-15 12:27 (UTC)

You're right lechu, I'll add that executable in the next version. Thank you for alerting me about that

lechu commented on 2021-10-15 12:12 (UTC) (edited on 2021-10-15 12:12 (UTC) by lechu)

Hi, salesforce cli now contains two executables:

I guess there should also be a link for sf like this:

ln -s /opt/sfdx-cli/bin/sf "${pkgdir}"/usr/bin/sf right?

dangmai commented on 2021-05-11 02:04 (UTC)

I've updated this package to the latest version distributed by Salesforce, and also fixed the detached HEAD issue with the AUR repository.

dangmai commented on 2021-04-18 17:14 (UTC)

@hashworks I'll fix that soon, and also update to the latest version. Salesforce keeps messing up their URLs for the downloads so I'll have to change the source code that generates this package pretty heavily anyway.

hashworks commented on 2021-04-18 16:49 (UTC)

This repo has a detached HEAD / no branch set. Could you fix that?

dangmai commented on 2020-11-03 15:24 (UTC)

@emadelsaid, thank you for the tip, hopefully it will solve problems for people.

emadelsaid commented on 2020-11-03 14:24 (UTC)

@ebu I had the same problem and the solution for me is to install seahorse when I opened it I found one key in the default keyring for '' I deleted it and tried to login again and it worked

dangmai commented on 2019-11-11 15:14 (UTC)

Awesome, thank you for the tip @mprom!

mprom commented on 2019-11-11 14:44 (UTC)

If you run into problems when trying to authorize, with " No such interface 'org.freedesktop.Secret.Collection' on object at path /org/freedesktop/secrets/collection/login", and you have a keyring like gnome-keyring installed, chances are it's because you're not using a display manager to handle it. Try looking here:

ebu commented on 2019-07-05 07:42 (UTC)

@dangmai, thanks,

dangmai commented on 2019-07-04 17:51 (UTC)

@ebu Yes it does work on Linux for many people, me included. It doesn't really matter what graphical environment that you use, since this is a CLI program. You're the second person to have run into this particular issue though, so I'll dig a bit deeper to see if I can find anything.

ebu commented on 2019-07-03 14:57 (UTC) (edited on 2019-07-03 14:57 (UTC) by ebu)


When I use this command sfdx force:auth:web:login -d -a DevHub --loglevel debug

I have this error ERROR running force:auth:web:login: Invalid key length

And in sfdx.log {"name":"sfdx","hostname":"shigoto","pid":4753,"log":"AuthWebLoginCommand","level":50,"msg":"[ '\u001b[1mERROR running force:auth:web:login: \u001b[22m',\n '\u001b[31mInvalid key length\u001b[39m' ]","time":"2019-07-03T14:45:13.705Z","v":0}

I use cinnamon v4.0.10

sfdx --version

sfdx-cli/7.13.0-27dbcb37d3 linux-x64 node-v10.15.3

Does sfdx work under linux ? if yes, with which graphical environment ?

dangmai commented on 2019-04-01 03:19 (UTC)

Salesforce is no longer distributing the i686 version of this package, so I'm taking that version off of AUR. The only supported version now is x86_64 for this package. They also distribute an ARM version but I'm not sure if anyone would use it; if it's beneficial for you please put a comment here and I'll support that version as well.

dangmai commented on 2019-02-28 17:35 (UTC)

@fandancer are you a developer? If you are you can put a few console.log in /opt/sfdx-cli/node_modules/salesforce-alm/dist/lib/crypto.js around line 162 to explore the state at the time of the error. Usually that helps narrowing down why things don't work. If not then I'm not sure what else to try, since I can't reproduce this issue.

fandancer commented on 2019-02-28 17:26 (UTC)


gnome-keyring: 3.28.2 node v11.10.0

I uninstalled the nodejs package and still have the same problem unfortunately...

dangmai commented on 2019-02-28 16:29 (UTC)

@fandancer that's very weird. I looked into the source code distributed by Salesforce and nothing looks out of place. Also I do know this package works for multiple people on Arch/Manjaro/Antergos so I'm a bit stumped why it doesn't work for you.

Here are a couple of things that I can think of: - Did you install gnome-keyring? - Do you have node installed by pacman in your system? If yes, which version? (sfdx-cli brings its own embedded Node 8.9.4 but maybe there's something going on with your PATH)

fandancer commented on 2019-02-28 13:33 (UTC) (edited on 2019-02-28 13:34 (UTC) by fandancer)

I'm getting a lot of errors relating to the /opt/sfdx-cli files but these are deleted on reinstall.

{"name":"sfdx","hostname":"test","pid":26637,"level":50,"msg":"[ false,\n  '{\"message\":\"Invalid key length\",\"status\":1,\"stack\":\"Error: Invalid key length\\\\n    at new Cipheriv (crypto.js:219:16)\\\\n    at Object.createCipheriv (crypto.js:619:10)\\\\n    at Crypto.encrypt (/opt/sfdx-cli/node_modules/salesforce-alm/dist/lib/crypto.js:162:31)\\\\n    at Object.keys.forEach (/opt/sfdx-cli/node_modules/salesforce-alm/dist/lib/configValidator.js:68:36)\\\\n    at Array.forEach (<anonymous>)\\\\n    at crypto.init.then (/opt/sfdx-cli/node_modules/salesforce-alm/dist/lib/configValidator.js:59:37)\\\\n    at tryCatcher (/opt/sfdx-cli/node_modules/bluebird/js/release/util.js:16:23)\\\\n    at Promise._settlePromiseFromHandler (/opt/sfdx-cli/node_modules/bluebird/js/release/promise.js:510:31)\\\\n    at Promise._settlePromise (/opt/sfdx-cli/node_modules/bluebird/js/release/promise.js:567:18)\\\\n    at Promise._settlePromise0 (/opt/sfdx-cli/node_modules/bluebird/js/release/promise.js:612:10)\\\\n    at Promise._settlePromises (/opt/sfdx-cli/node_modules/bluebird/js/release/promise.js:691:18)\\\\n    at Async._drainQueue (/opt/sfdx-cli/node_modules/bluebird/js/release/async.js:138:16)\\\\n    at Async._drainQueues (/opt/sfdx-cli/node_modules/bluebird/js/release/async.js:148:10)\\\\n    at Immediate.Async.drainQueues (/opt/sfdx-cli/node_modules/bluebird/js/release/async.js:17:14)\\\\n    at runCallback (timers.js:789:20)\\\\n    at tryOnImmediate (timers.js:751:5)\",\"name\":\"Error\",\"warnings\":[]}' ]","time":"2019-02-28T13:27:36.725Z","v":0}

dangmai commented on 2019-02-27 17:21 (UTC)

Apparently there is, here's the documentation:

fandancer commented on 2019-02-26 09:12 (UTC) (edited on 2019-02-27 12:46 (UTC) by fandancer)


I run the commands:

pacman -R sfdx-cli

rm -rf ~/.local/share/sfdx

yay sfdx-cli

sfdx update

sfdx force:auth:web:login

And I'm still hitting the same error, is there a log to view to check the error?

Edit: Thought I could get around this by making an ubuntu VM and logging in there, then copying the json files for that user into my Arch install. Ubuntu works fine, but when I try the command sfdx force:org:open -u I get the same invalid key length error

dangmai commented on 2019-02-25 15:39 (UTC)


pacman -R sfdx-cli should delete everything related to this package. However, I do know that sfdx also puts some stuff in your $HOME/.local/share/sfdx directory (especially when you do sfdx update instead of using pacman to update).

fandancer commented on 2019-02-25 08:10 (UTC) (edited on 2019-02-25 08:10 (UTC) by fandancer)



Gnome 3.30.2

sfdx-cli/6.53.0-67a9cbb60c (linux-x64) node-v8.9.4


Which files to I need to delete to ensure a complete reinstall of sfdx-cli?

dangmai commented on 2019-02-22 15:47 (UTC)

@fandancer, I just logged in using sfdx force:auth:web:login on a new Antergos installation, so I think there's something going on with your installation. Which DE are you running (is it on X11 or Wayland)? Can you do sfdx --version and post the output?

fandancer commented on 2019-02-22 10:27 (UTC)

I'm still getting errors during login. Attempting web:login causes the error "Invalid Key Length". Where as all attempts using JWT flow causes the error "invalid_grant - invalid assertion"

dangmai commented on 2019-02-05 05:27 (UTC)

That's great to hear, thanks zerkz!

zerkz commented on 2019-02-04 20:07 (UTC) (edited on 2019-02-04 20:10 (UTC) by zerkz)

With the latest packages in my arch/gnome setup installed, SFDX CLI now seems to properly work out of the box for the "web oauth flow".


GNOME 3.30.2

sfdx-cli 6.50.0_9817aece8a-1

zerkz commented on 2018-11-28 18:54 (UTC)

@dangmai I pinged the lead of the CLI team to bring up this issue and ask for package updates.

@YodaDaCoda thanks for the workaround! i was playing with doing something similar last night but I noticed that opn is referenced by various modules as a dependency and didn't update them all to 5.4.0. (5.4.0 is the fix for GNOME 3.30 I believe, pretty recent).

dangmai commented on 2018-11-28 16:26 (UTC)

@YodaDaCoda yup that would work! The downside is that every time this package gets updated you'll have to do that again (until Salesforce actually fixes the dependencies). Also, you probably mean opn instead of open in your command :)

YodaDaCoda commented on 2018-11-28 00:31 (UTC)

I overwrote the bundled version of xdg-open and am able to perform auth now. This may serve as a workaround until upstream fixes dependencies.

sudo cp /usr/bin/xdg-open /opt/sfdx-cli/node_modules/open/vendor/xdg-open

dangmai commented on 2018-11-26 18:00 (UTC)

@zerkx @dhbahr I've managed to track down why it's not working. sfdx-cli is using an old version of the node package opn, which in turn uses an old version of xdg-open that calls non-existent programs on GNOME > 3.30 (It tries to call gvfs-open and gnome-open, whereas the correct binary to use is now gio open). This is not something that I can fix for this package - you should bug upstream so they update their dependencies.

dangmai commented on 2018-11-26 17:23 (UTC)

@zerkx @dhbahr I managed to reproduce this on a freshly installed Antergos w/ Gnome. Not sure why it's happening either but I'm going to debug it a bit more.

zerkz commented on 2018-11-26 14:35 (UTC) (edited on 2018-11-26 14:35 (UTC) by zerkz)

@dangmai I also reproduced the same issues @dhbahr is having. I am running X11 Gnome 3.30.2 (Antergos), and was only able to get the browser to open up using sudo, but then it fails later (presumably trying to unlock the active user's keyring, in which it cant under sudo?).

I was able to get around it via using the force:auth:jwt:grant flow, but its a rather lengthy workaround...

dangmai commented on 2018-11-23 17:55 (UTC) (edited on 2018-11-23 21:41 (UTC) by dangmai)

@dhbahr I haven't run into that issue before, but I run Cinnamon so there may be differences with Gnome that I'm not aware of. Are you running X11 or Wayland?

dhbahr commented on 2018-11-07 10:50 (UTC)

@dangmai, running on gnome I'm getting nothing when trying to authenticate the DevHub through the web login flow. My experience is exactly the same as in this question: and can only get the browser window to open if I run it with sudo. Even running sudo -u myuser sfdx force:auth... gets the browser to authenticate me, but if I try it without sudo nothing happens, not even in the logs. Not saying it's a package issue, just wanted to check if you know a way to solve this.

dangmai commented on 2018-06-24 19:56 (UTC)

Updated to 6.21.0, and gnome-keyring has been added to optdepends in order to save default credentials

dangmai commented on 2018-06-19 15:08 (UTC)

@mprom, that's a good point. I think I'll put it as an optional dependency since it's not required to run sfdx-cli. It's a bit strange that KDE doesn't provide a service to do the same thing.

mprom commented on 2018-06-19 12:20 (UTC)

You should add gnome-keyring as a dependency, as without it the sfdx force:auth:web:login --setdefaultdevhubusername command will fail with

ERROR:  Command failed with response.
 - ** Message: 14:07:47.574: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files
secret-tool: The name org.freedesktop.secrets was not provided by any .service files

I'm running KDE myself, but couldn't find any KDE-related service to do the same

dangmai commented on 2018-04-27 02:52 (UTC)

Updated to sfdx-cli 6.13.0_3bc8bd73d8.

Note: sfdx-cli stores a local copy in your $HOME/.local/share/sfdx so that it can be automatically updated when you run the program, so sfdx update is the preferred way to keep it up to date.