Qpdf fails to encrypt without passwords - encryption

I'm trying to add restriction to a pdf file, but don't need a user password. I fail to get this right for some reason.
qpdf.exe --encrypt 40 -modify=y -extract=y -annotate=y -- in.pdf out.pdf
The help states that:
Either or both of the user password and the owner password may be empty strings.
How should I specify the empty password strings?

You should use quotation marks to specify empty strings as password:
qpdf.exe --encrypt "" "" 40 -modify=y -extract=y -annotate=y -- in.pdf out.pdf

Related

How can I prevent the saving of incorrectly decrypted files?

When I enter the incorrect password for an encrypted file Vim displays gibberish.
If I accidentally save this file (:wq is muscle memory) I will lose the original content. How do I prevent the save of incorrectly decrypted files? Is it possible to set the 'readonly' option when the file is decrypted incorrectly?
Additional question - Is it possible to recover the original content of the file after we have saved the incorrectly decrypted file?
PS - I was using :se cm=blowfish2
How do I prevent the save of incorrectly decrypted files?
Adding the following map to .vimrc prevents mistakenly overwriting an encrypted file by asking the user if he/she really wants to quit:
au BufWinEnter * if &key!="" | cnoremap wq if input("Sure of quitting encrypted file? (yes or no)") == "yes"\|wq\|endif|endif
The important part here is the &key!="" comparison which evaluates to TRUE only if the file is encrypted.
Is it possible to set the 'readonly' option when the file is decrypted incorrectly?
An incorrectly decrypted file will often display unusual characters. This can help to detect whether a file is incorrectly decrypted, like so if search("[¶Éâ½]")!=0 | set readonly | endif. This comparison evaluates to TRUE if any of the characters inside "[]" appear on the file.
Is it possible to recover the original content of the file after we have saved the incorrectly decrypted file?
From :help encrypt
WARNING: If you make a typo when entering the key and then write the file and exit, the text will be lost!

How to hide/asterisk a part of the code in R?

I have put in a password inside my code in Rstudio and I just want to somehow make it unclear so when I show my code to someone they don't see the password. Any suggestions for how to do this?
Thanks much
you should make a new R script (let's call it login_credentials.R) and store your password there
username <- "username_here"
password <- "password_here"
Once you save that, you can then load that script using source()
This will load the username and password variables.
source(login_credentials.R)
> username
[1] "username_here"
> password
[1] "password_here"
login_function(username,password)
You can obscure your password in the source file.
You can run something like
dput(charToRaw("Password"))
# as.raw(c(0x50, 0x61, 0x73, 0x73, 0x77, 0x6f, 0x72, 0x64))
to get numeric dump of your password. Then you can include in your script
pwd <- as.raw(c(0x50, 0x61, 0x73, 0x73, 0x77, 0x6f, 0x72, 0x64))
login("username", rawToChar(pwd))
That will at least make it less-human-readable and there won't be a variable in the environment browser with the text value (at least I think, i'm not sure how RStudio displays raw data).
You could create a .Renviron file in either your home directory or your project directory, where you store info like this in an environmental variable for use in your R scripts.
If this is the content of ~/.Renviron or /path/to/my/project/.Renviron:
YO=secretsecret
Then you can retrieve secretsecret via Sys.getenv("YO"). I wrote up how to do this for API authentication here.
Note: It can be very important to make sure your .Renviron file ends with a line break! Also, you'll need to restart R or Rstudio before this takes effect. Read up on R startup for more general info.
getPass package would be helpful in your case. This package has a function getPass() which is similar to readline(), the only differnce is that user's text is not printed as it is typed.
For example, consider that the following command creates connection to a database where you normally type the username and password.
Connection <- dbConnect(driver, connection_parameters, UserName, Password)
Try replacing the password with getPass() function:
library(getPass)
Connection <- dbConnect(driver, connection_parameters, UserName, getPass())
So whenever you run this line of code, you would see a popup window asking you to enter ur password. The password would not displayed as you type, but it would be masked as dots (or asterisk).
Password PopUp window
Though this requires you to enter the password every time you run, it at least gives you the ability to mask passwords.
Arguments for the function would be:
getPass(msg = "PASSWORD: ", noblank = FALSE, forcemask = FALSE)
A slightly more secure solution would be to store a hash of your password. This can be achieved with the digest function:
> digest::digest("password")
[1] "380796939c86c55d6aa8ea8c941f7652"
This implements the MD5 hash which is a one way cryptographic function and the original password can't be retrieved from this hash, i.e. there is no inverse function.
You will then need to modify the part of your code where you enter the password, hashing the entered password:
# Username and password part of code
username <- "username_here"
password_hash <- "380796939c86c55d6aa8ea8c941f7652"
...
# Password testing part of code
if (digest::digest(user_password_input) == password_hash){
"password_correct"
}else{
"password_incorrect"}
where user_password_input is a variable containing the entered password. The hashed password is secure because even if someone has your hashed password, they can't use it to get past the password verification. If they do enter the hash of you password it will be re-hashed and different to the password_hash variable.
Using hashes is good practice as your actual passwords are never stored in the code and the hashes by themselves are no use.

Paw Basic Auth line break character

There seems to be a bug with Basic Auth in Paw. The password field is added a \n character to the end of the password I enter and breaks my authentication on the server side. You can even see the extra line after the password in this screenshot. I've also confirmed in my server-side code that there is indeed a newline character (\n) appended to the string.
http://note.io/12BJA6m
It sounds like you added a newline character after the password. Edit the password field, select all, and type the password again.
(Though, I agree the field shouldn't accept newlines, I'll file a bug for that.)

HTTP/HTTPS basic authentication: colon in username

This may be a basic question, but is it possible to have colon (":") in username when there is HTTP or HTTPS basic authentication ? If not, is there a way we can escape colon ?
the RFC https://www.rfc-editor.org/rfc/rfc2617#section-2 states clearly that the username must not include a colon:
To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials.`
basic-credentials = base64-user-pass
base64-user-pass = <base64 [4] encoding of user-pass, except not limited to 76 char/line>
user-pass = userid ":" password
userid = * <TEXT excluding ":">
password = *TEXT
Based on this, there is no way to use a colon within the username.
Looking at RFC - https://www.rfc-editor.org/rfc/rfc2617#section-2 and around the web, there doesn't seem to be escaping technique for colon in username. The only place extra you can have it is in password field.
If it is an option, you maybe can replace : with # in auth level and ask users to do this.

How do I list information for a GnuPG encrypted message?

I'm still working with GPG, as in this post:
How do I encrypt plaintext with GnuPG?
What I need now is to be able to list various info (e.g. all recipients) of an encrypted message without necessarily decrypting it. I've seen links to different commands like "--list-only", but nothing seems to work. Does anyone have an authoritative reference (or any input really) on this?
Best.
EDIT #1:
Clarification. --list-only will display all keys but your own (if it was encrypted to you). Basically I need to be able to determine if the item was encrypted to me so as to "file" it or take other action.
In order to see all keys (that are not hidden) that a block of encrypted data was encrypted to - including your own - you could simply make your secret-keyring unavailable, via something like this:
gpg --no-default-keyring --secret-keyring /dev/null -a --list-only
That tells gpg to not use any default keyrings (--no-default-keyring) if an invalid/missing keyring is specified, and then goes on to specify an invalid/missing secret-keyring (--secret-keyring /dev/null)

Resources