~ghewgill

Christchurch, New Zealand

https://hewgill.com

~ghewgill/neon-discuss

Last active 28 days ago

~ghewgill/neon-devel

Last active 28 days ago

~ghewgill/neon-announce

Last active 28 days ago
View more

Recent activity

Re: SVG file embedded in README.md 17 days ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

May 12, 2020 1:13 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> This is indeed a concern. In theory it's not unfixable, but the overhead
> of implementing SVG is higher than for any other image format.

Thanks. Whoever thought it was a good idea to ruin a perfectly good
image format with scripting.

I'll stick with the PNG image for now and hope nobody ruins that. :)

Re: SVG file embedded in README.md 17 days ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

May 11, 2020 8:56 PM, "Simon Ser" <contact@emersion.fr> wrote:

> I wonder whether this may be a security issue (users would be able to
> potentially embed JavaScript in the SVG and steal cookies).

That could be the reason. That would be unfortunate too, because SVG
is a nice way to include simple diagrams (I even tried inline SVG in
the Markdown, but that definitely did not work).

I've added a PNG version of the diagram for now so it works, but have
left the broken link to the SVG in there. I'm still hoping that there
is some way to make the SVG work.

SVG file embedded in README.md 17 days ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

I'm trying to embed an SVG in a README.md file served from git.sr.ht.
Project link: https://git.sr.ht/~ghewgill/hour-of-power

The problem is the SVG file appears to be served with a
"Content-type: text/plain; charset=utf-8" header. This causes the
browser to fail to render the SVG as an image.

How can I cause the SVG file to be served with "image/svg+xml" type?
Or is there another better way I'm missing?

Re: Automatic builds launching 2 months ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

March 17, 2020 11:28 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> I can help you if you share a link to your repo? There's a lot of
> different ways it gets messed up.

Sure, I'll take this off-list for diagnostics.

Re: Automatic builds launching 2 months ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

March 17, 2020 11:08 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> git.sr.ht rewrites the clone URLs on submission to match whichever repo
> it was pushed to. So when your collaborator pushes to their repo, the
> clone URL will be rewritten and the job will build their code. However,
> any secrets you've included in your manifest will not be added to their
> build environment.

Ok, sounds reasonable. I don't have any build secrets, so that's not an
issue. I've just had reports that some pushes to their repo does not trigger
build jobs to be created. I don't have much visibility into why this might
be happening, so I was looking at the docs to try to find a reason.

What are the possible reasons that build jobs might not be created, or

Automatic builds launching 2 months ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

I've got a question about how the builds.sr.ht integration is supposed
to work. I have a repository that has some yml files in the .builds/
directory, and it works fine for me when pushing code to git.sr.ht. That
is, build jobs are created and started on builds.sr.ht when I push.

If I have a collaborator who is working with a clone of the code in
their own git.sr.ht repository, are the automatic build jobs supposed
to be started when they push? From man.sr.ht: 

> git.sr.ht will automatically submit builds for you if you store a
> manifest in the repository as .build.yml. Each time you push, a
> build with this manifest will be submitted. If the repo you pushed
> to is present in the manifest's sources array, we'll edit it to point
> to the ref you just pushed.

Re: Exposure of ssh public keys 2 months ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

March 5, 2020 6:39 PM, "Drew DeVault" <sir@cmpwn.com> wrote:

> This issue has been discussed before. As some have pointed out, your SSH
> public key is a _public_ key. It's tautological.

To be clear, I cannot object to the *key* part of the public key
being made public. However, the *comment* part, which is a name
that is meaningful to me only, should not be exposed in the public
list of keys. In order to be meaningful to me, the name is likely
to expose some aspect of my client setup, and I don't want to remove
that or substitute the actual machine names/locations with code
words.

I would be happier if the public list of keys omitted the name part.

Re: Exposure of ssh public keys 2 months ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

March 5, 2020 5:00 PM, "Victor Goff" <keeperotphones@gmail.com> wrote:

> It is similar on github: https://github.com/username.keys
> and gitlab: https://gitlab.com/username.keys

I notice that github does not expose the key comment (name) in this case.

Exposure of ssh public keys 2 months ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

I was a bit surprised to see that on my https://meta.sr.ht/keys page,
there is a way to see anybody's public ssh keys at

    https://meta.sr.ht/%7Eusername.keys

Recommended key hygiene says that one should create a new key for every
client system that you work on. With this, the key comments (name) can
reveal quite a lot about the systems in use by a sr.ht user. I know that
the key name can be changed, but in my view the names should be for *my*
use, not the world at large.

In short, the set of ssh keys I use are business between me and the ssh
server(s) that I want to connect to. Not anybody else's business.

Re: Supporting user groups/organizations on SourceHut 3 months ago

From Greg Hewgill to ~sircmpwn/sr.ht-discuss

February 15, 2020 4:40 AM, "Drew DeVault" <sir@cmpwn.com> wrote:

> That being said, the subtleties here are really difficult. I'm
> definitely going to put more thought into the payment model for
> organizations.

As an individual user of SourceHut, I wouldn't want my personal SourceHut
account to subsidise my company's simultaneous use of SourceHut. I would
expect that my employer would pay for an employee's use of SourceHut
regardless of whether that employee already had their own personal account.
I think keeping the accounting separate is a benefit to both employer
and employee.