pdobsan / oama

OAuth credential Manager
BSD 3-Clause "New" or "Revised" License
129 stars 10 forks source link

feature request: option to specify location of gpg encrypted file #61

Closed newhallroad closed 4 weeks ago

newhallroad commented 3 months ago

Thanks for an excellent project.

I am running oama on a Windows 10 machine inside WSL2. It would be helpful if there was an option to be able to specify the location of the gpg encrypted file.

Longer explanation

oama works perfectly inside WSL2. But I would also like to access it from windows as a wsl binary. However, the windows system doesn't recognize the internal path. Thus, from inside a WSL terminal (Ubuntu in my case), oama access user@gmail.com works perfectly. But from the Windows cmd cli, I get the following:

$ C:\Users\user>wsl oama access user@gmail.com
gpg: can't open '/home/user/.local/var/oama/user@gmail.com.oama': No such file or directory
gpg: decrypt_message failed: No such file or directory

I believe that if I could store the encrypted file on the windows filesystem and specify the path to oama, then it would work both from within WSL and from the Windows cli.

The reason I want this is to be able to send email from inside Gnu emacs for Windows by integrating oama with msmtp. But this can only be done if emacs can run oama via WSL2.

I understand if this might be too niche a requirement to bother working on, but if you were willing to consider it, I would be very grateful. Or, if you have any other suggestions for a work around, that would also be great. (I have been wondering about using cross-platform password managers but my experimentations have not been successful. I am pretty new at this so I might be missing some ideas.)

In any case, thank you very much for all of your generous contributions to the community and for this excellent project.

my printenv

###  Runtime environment  ###
config:
  encryption:
    contents: <GPG_key_id>
    tag: GPG
  services:
    google:
      access_type: null
      auth_endpoint: null
      auth_http_method: null
      auth_params_mode: null
      auth_scope: null
      client_id: <client_id>
      client_secret: <client_secret>
      prompt: null
      redirect_uri: null
      tenant: null
      token_endpoint: null
      token_http_method: null
      token_params_mode: null
config_file: /home/user/.config/oama/config.yaml
data_dir: /home/user/.local/var/oama
oama_version: '0.14'
op_sys: |
  Linux MACHINE_NAME 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
options:
  optCommand:
    tag: PrintEnv
  optConfig: ~/.config/oama/config.yaml
  optDebug: false
services:
  google:
    access_type: offline
    auth_endpoint: https://accounts.google.com/o/oauth2/auth
    auth_http_method: POST
    auth_params_mode: QueryString
    auth_scope: https://mail.google.com/
    client_id: <client_id>
    client_secret: <client_secret>
    prompt: consent
    redirect_uri: null
    tenant: null
    token_endpoint: https://accounts.google.com/o/oauth2/token
    token_http_method: POST
    token_params_mode: RequestBody
######
pdobsan commented 2 months ago

I am relying on github's email service to monitor issues and somehow I have not received email about this issue. I have just discovered it now.

Anyway, it looks to me that this is a problem of accessing file systems inside WSL from windows and vice versa. I assume you want to use the same config file for both use cases.

I am not familiar with WSL but based on some cursory search, one can pass environment variables to WSL processes from windows: https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/

At the moment data_dir is defined to $HOME/.local/var/oama so passing a changed HOME envvar might work with some trickery.

I might consider making data_dir configurable at some later stage but don't hold your breath.

newhallroad commented 2 months ago

Understood! Thanks for considering.

pdobsan commented 1 month ago

I have made the credential storage location configurable through the XDG_STATE_HOME envvar. For details please see the README. New release coming soon.

newhallroad commented 3 weeks ago

How wonderful. Thanks for this.

On Tue, Oct 8, 2024 at 4:52 PM Peter Dobsan @.***> wrote:

I have made the credential storage location configurable through the XDG_STATE_HOME envvar. For details please see the README. New release coming soon.

— Reply to this email directly, view it on GitHub https://github.com/pdobsan/oama/issues/61#issuecomment-2400800026, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMLEUF2DVEFLMPIB3UDLADZ2RAZHAVCNFSM6AAAAABMKY4IQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBQHAYDAMBSGY . You are receiving this because you authored the thread.Message ID: @.***>