Skip to content
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

RPC credentials exposure #9

Closed
kseistrup opened this issue Mar 6, 2016 · 4 comments · Fixed by #103
Closed

RPC credentials exposure #9

kseistrup opened this issue Mar 6, 2016 · 4 comments · Fixed by #103

Comments

@kseistrup
Copy link

Taking RPC credentials on the commandline potentially make these credentials available to any user that is able to run the ps(1) [or similar] command. ncdt and ncdumpzone ought to be able to find the necessary values in a config file or in environment variables.

@JeremyRand
Copy link
Member

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/06/2016 05:46 AM, Klaus Alexander Seistrup wrote:

Taking RPC credentials on the commandline potentially make these
credentials available to any user that is able to run the |ps(1)|
[or similar] command. |ncdt| and |ncdumpzone| ought to be able to
find the necessary values in a config file or in environment
variables.

Related: implementing support for Namecoin Core's REST API would make
this a moot issue, and would also improve usability.

Are there use cases where RPC is actually needed for these tools? I
think name_scan and name_filter are still unsupported by REST, but
that seems like something that should be resolved by Namecoin Core,
not by ncdns. Namecoin 0.3.80 doesn't support REST, but since it's
going to be hardforked off the network by BIP9 fairly soon, breaking
ncdns compatibility with 0.3.80 doesn't concern me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXHudoAAoJEAHN/EbZ1y06YZIP/0hE9wCT+mWFV2rN3hMEgEzU
xcjP82BnJY93+58exGxgzXSgs+3WXT3WWTVcHu7Z855ptv4nopulBL90MvFgsPSW
BbEf17fEDAmigBDw4gPpXBnz+tpfmgdT5D2/+PLqGlpTDYrzAF+SRB05gExDWlt1
byuE1AyBJjAwaLZDytfnSEFo4/otG//Gb9HmBBgGD0YYLrqc0gksHeLB3dAshbAU
KoGNbC8plZ6vBSbwXkJyB/Au15rScgx73735Jiqadloil8xizpOpEco1XnEGH7aC
QJnCqyoRljQhWt+gIY1s4okdRMjGGgYncd+z3mplDv9Rq3FtIvPdmmrtZMLxNlLJ
1Kc2j1jQSTNUM8aOh8w11JU7ChK5u3NbKvdyUQIt3oLLe9oVUD4wMlv+laz98+Za
gqca5dgI50WUfh/LE/PvPFYSqMSOiWlFtGdNzqKYocb74wJnpeuz0p4wIFM4SRHQ
4BvHqs1+tVT8yPup4TTvoLevOQ4ztFLsbpyWlL3NAXSK22g+v34X3jnoErz5D9jK
NTbDVvmLx4YHlAt+V9BUQRRSFuNVVZvbzCq78/WKtxK32mujtCMyD7p+CyEUWxid
U2sAJTLiRybDHk5jFTH8FcHTA4bs+1egbQHZu30CLl/N4OzQ8EqUTLkk3zFYHfLU
1BRv3UmUtF9Q7oG7qUH2
=AS6k
-----END PGP SIGNATURE-----

@JeremyRand
Copy link
Member

JeremyRand commented May 12, 2018

@hlandau is there a reason why ncdumpzone and ncdt are using kingpin and flag rather than easyconfig? Seems like migrating them both to easyconfig (like ncdns) would solve this issue.

@hlandau
Copy link
Contributor

hlandau commented Jun 1, 2018

@JeremyRand I wrote it as a command line tool, so intended for manual invocation without the flexibility of configuration that daemons require, for which easyconfig is used. But I don't see an issue with migrating it to easyconfig.

@JeremyRand
Copy link
Member

#76 solves this for ncdumpzone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants