Rejecting. See #32.

@dolmen, I do see what you mean. github-keygen should not force more restrictive permissions than what are required by ssh. I do however feel that github-keygen should make it easy for people to set up github keys, including correcting the file permissions, if they are too permissive, to the point that ssh will not accept them. I propose making a slight change to the PR with, checking the current rights and only changing them to the loosest acceptable mode (0660?) should they be too permissive.

Your patch is about ~/.ssh/config, not about the key files.

Then I would prefer to report a "too wide permission" issue as a fatal error (with a fix suggestion) rather than silently "fixing" the issue. Your patch is just breaking the promise of transparency I made to the users. This is important to keep users' trust.

Quite true, but ssh puts restrictions on the allowed permissions of the config file too. The config file must not be writable to anyone but owner, lest ssh returns 255 and spits out Bad owner or permissions on ~/.ssh/config.

I suggest that instead of setting the full mode, the patch instead just strips off write access from others and group, thus retaining the permissions otherwise.

e.g.

    # strip [g]roup and [o]thers write access
    my $mode = (stat SSH_CONFIG_FILE)[2] & 07755;
    chmod $mode, SSH_CONFIG_FILE;

I suggest that instead of setting the full mode, the patch instead just strips off write access from others and group [...]

As I already wrote above, my policy on this project is to not do things silently. So this patch is still not acceptable.
I have instead committed fd4d9f7.