impl

I believe the current attempt at mitigation for this is ASPA[0]. It still has a long way to go, but there are some big names behind it.

[0] https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-asp...

This website is at least 25 years old. It uses one of the pre-canned templates from FrontPage 2000. Cut 'em a little slack. :-)

This was obviously someone's research project, and some of the papers have example code in them, e.g. see https://www.cs.cornell.edu/talc/papers/talx86-wcsss.pdf.

Too bad they don't take security so seriously themselves.

https://pagedout.institute/?page=/etc/passwd

;-)

Zero interest rate policy, which makes borrowing lots of money almost free, which makes it easy to hire lots of people using said borrowed money.

No. When you finance a car the lender gets a lien on the title. The title is still in your name. Usually one of the stipulations the lender places in their contract is that they hold the title for you in what is effectively "escrow" until the loan is paid off. Then they release the lien and send you your title.

The reason they do that is because a lien gives them the ability to, within a particular legal framework, get ownership of the car if you don't pay your loan, prevent the title from being transferred to someone they don't trust, etc. It's basically just risk mitigation.

This is cool. I like the frontend aspect. Looks really handy for a lot of apps where integration with other services is a core feature (I've built several just over the past few years, so I definitely get it).

I do wish it supported encrypted storage. For example, I wrote/maintain a Vault plugin to do basically the same work as the backend side of this project[0]. I wonder if you would be interested in supporting Vault as a backend in addition to PostgreSQL down the line? Feel free to reach out if so.

To answer your question:

Like some others here, I haven't found the actual integration points to be terribly difficult with most OAuth 2 servers. Once you have a token, you can call their APIs. No problem. I wrote the Vault plugin I referenced above to basically just do automatic refreshes without ever exposing client secrets/refresh tokens to our services, and it works fine.

Rather our customers would get into situations where they inadvertently revoked access, the user that authorized the integration initially left the company and it was automatically disabled, etc. and there was no notification that it happened. Basically all of the lifecycle management side that couldn't be automated down to "refresh my token when it's about to expire" sucked. So anything you're looking to support there would be a huge value-add IMO.

Another one is that each provider has their own scope definitions/mapping to their APIs. Some scopes subsume others (e.g. GitHub has all repos, public repos, org admin, org read-only, etc.). Some get deprecated and need to be replaced with others on the next auth attempt. We could never keep them up to date because they were usually just part of docs, not enumerated through some API somewhere. If you had a way to provide the user with a way to see and select those scopes in advance, that would be huge. Think if my app or a user could answer the question "I want to call this API endpoint, what scopes do I need?" by just asking your service to figure it out.

[0] https://github.com/puppetlabs/vault-plugin-secrets-oauthapp

If anyone's looking for an example, I used this trick a few months ago to embed a tiny helper binary[0] directly into my application[1] so I wouldn't have to ship two executables or add "hidden" behavior to the main program. It works really well (on Linux)!

[0] https://github.com/impl/systemd-user-sleep/blob/666cf29871b1...

[1] https://github.com/impl/systemd-user-sleep/blob/666cf29871b1...

Relay by Puppet | Senior Software Engineer | Portland, OR or remote (5 hour overlap with Pacific Time) | Full-time | https://puppet.com and https://relay.sh

Hi!

Relay is Puppet's fast-moving SaaS/PaaS endeavor into the cloud-native arena. Relay is an event-driven workflow execution engine that helps connect service APIs and infrastructure.

We're looking for a senior-level backend engineer[0] keen on DevOps and security to make our workflow execution system robust and powerful. Our stack is pragmatic: lots of Go, Kubernetes (we run untrusted user-specified containers), Tekton, Knative, all in GCP.

In non-pandemic times, Puppet has a sweet office in downtown Portland (but you're welcome to remain remote, too). We're a friendly bunch (well, I'd like to think so anyway) and we're absolutely committed to making our customers' lives better every day. If this sounds like something you'd be interested in, please apply!

And if you have any questions or just want to chat, feel free to shoot me an email at noah@puppet.com.

(Note: No recruiters, please.)

[0] https://puppet.com/company/careers/jobs/2808521

Puppet | Senior Software Engineer | Portland, OR or remote (5 hour overlap with Pacific Time) | Full-time | https://puppet.com

Hi!

Relay[0] is Puppet's fast-moving SaaS/PaaS endeavor into the cloud-native arena. Relay is an event-driven workflow execution engine that helps connect service APIs and infrastructure.

We're looking for a senior-level backend engineer[0] keen on DevOps and security to make our workflow execution system robust and powerful. Our stack is pragmatic: lots of Go, Kubernetes (we run untrusted user-specified containers), Tekton, Knative, all in GCP.

In non-pandemic times, Puppet has a sweet office in downtown Portland (but you're welcome to remain remote, too). We're a friendly bunch (well, I'd like to think so anyway) and we're absolutely committed to making our customers' lives better every day. If this sounds like something you'd be interested in, please apply!

And if you have any questions or just want to chat, feel free to shoot me an email at noah@puppet.com.

[0] https://relay.sh

[1] https://puppet.com/company/careers/jobs/2808521

Hi,

I wrote an SSH step for you. Here's the source code:

https://github.com/relay-integrations/relay-ssh/blob/master/...

And since it isn't documented yet, here's how you would use it in a workflow:

  steps:
  - name: ssh
    image: relaysh/ssh-step-exec
    spec:
      connection: !Connection {type: ssh, name: my-ssh-connection}
      username: relay
      port: 2222 # defaults to 22
      knownHosts: |
        server1.example.com ssh-rsa AAAAEXAMPLE
        server2.example.com ssh-rsa AAAANOTHEREXAMPLE
      # or
      #strictHostKeyChecking: false
      on:
      - server1.example.com
      - server2.example.com
      input:
      - whoami
      - uptime
      - cat /etc/passwd

We do have a Helm integration that might be able to help you out: https://relay.sh/integrations/helm/

The limiting factor right now would be whether your cluster is accessible to the internet, which of course isn't super common. We are working through what our story for connecting to on-prem infrastructure looks like, so if you can provide any additional details on your environment, it would be helpful!

Thank you! I'll take a look through this! Would it be okay if I sent you an email in the next week or two for follow-up questions?

It varies. We have a primary PostgreSQL database for non-sensitive data including some workflow configuration. We store sensitive data in Vault and logs in Google Cloud Storage. A bit more info here: https://relay.sh/docs/how-it-works/#where-and-how-is-my-data...

I'm happy to answer any questions about our storage and security architecture too!

Hi,

This is a good question, thank you! The flow of events into our system is somewhat different than GitHub Actions. We're trying to be a consumer of all sorts of events, including, say, data published to AWS SNS or via a Docker Hub webhook[0]. All of that isn't quite in place yet, but we want to act more like an event broker than a CI/CD solution alone.

One concept we're throwing around is supporting CloudEvents[1] and dispatching workflows based on event types. If anyone has experience with CloudEvents we'd love to hear if that would be something useful to you.

[0] https://github.com/relay-integrations/relay-dockerhub/blob/m...

[1] https://cloudevents.io/

1) Please, please support some other config file other than just YAML.

Although we don't directly advertise it, you can in fact write a workflow in JSON and there's an underlying JSON interchange format that is authoritative in our system. We expect that any other languages we support would "compile" to this JSON format. What other languages are interesting to you? We've looked at CUE[0], HCL, and of course Puppet itself.

[0] https://cuelang.org/

A good book in this space is Normal Accidents[0], which describes (among others) the impressive cumulative failure that caused the Three Mile Island incident. Fascinating read and applicable to software systems as well.

[0] https://en.wikipedia.org/wiki/Normal_Accidents

This article is about nurses, though. In the US many ER nurses work 12 hour shifts and they obviously don't have the option of personal downtime. It's likely that as "computer" people we're already reaping much of the benefit discussed.

Right, but this project doesn't solve that problem, either. It wraps the underlying collection in a builder to make it less easy to access, but it doesn't appear that it places any additional restrictions on the types of members or collection elements (from the generated code on their site anyway).

If you weren't using this library, you could achieve something similar with, e.g.,

  someImmutableSet = Collections.unmodifiableSet(new HashSet<E>(someSet));

Actually, it does, but they don't have explicit types. See java.util.Collections.unmodifiableCollection(...), etc.

Try running it through an SSL-capable proxy like mitmproxy[0]. You should be able to get the full request/response details that way.

[0] https://mitmproxy.org/, https://mitmproxy.org/doc/ssl.html