Mh looks like @mnm678's and my approval do not count. @joshuagl can you have a look and approve this if fine?

@vaporup yes

Avoids output like

/home/swick/repos/vaporup/nspawn/nspawn {COMMAND} [PARAMETER]

or

./nspawn {COMMAND} [PARAMETER]

Now it always shows

nspawn {COMMAND} [PARAMETER]

@trishankatdatadog I don't have write access to the repository :D I guess you need to squash merge.

looks fine for me as well.

One addition: It may make sense to add a doc string if we make this public. This is very useful for generating Godocs.

@asraa can you add a a few sentences as doc strings above the function for documentation?

Hi,

I try to build rekor right now and there are a few failing tests.

Do I need to generate something special prior build? (Note: I don't use the makefile..) Right now I am building rekor-cli and rekor-server like this:

  export CGO_CPPFLAGS="${CPPFLAGS}"
  export CGO_CFLAGS="${CFLAGS}"
  export CGO_CXXFLAGS="${CXXFLAGS}"
  export CGO_LDFLAGS="${LDFLAGS}"
  export GOFLAGS="-buildmode=pie -trimpath -mod=readonly -modcacherw"
  go build -ldflags "-linkmode=external -w" -o cmd/rekor-cli/rekor-cli cmd/rekor-cli/main.go
  go build -ldflags "-linkmode=external -w" -o cmd/rekor-server/rekor-server cmd/rekor-server/main.go

closed with #378

This PR tries to solve #373 via checking for the ssh-keygen executable in the path. Note: The skipped tests will only be shown when adding the -v flag to go test. The PR has been tested on my local system:

❯ go test -v ./...
=== RUN   TestFromOpenSSH
    sign_test.go:144: skip TestFromOpenSSH: missing ssh-keygen in PATH
--- SKIP: TestFromOpenSSH (0.00s)
=== RUN   TestToOpenSSH
    sign_test.go:200: skip TestToOpenSSH: missing ssh-keygen in PATH
--- SKIP: TestToOpenSSH (0.00s)
=== RUN   TestRoundTrip
=== RUN   TestRoundTrip/rsa
=== RUN   TestRoundTrip/ed25519
--- PASS: TestRoundTrip (0.02s)
    --- PASS: TestRoundTrip/rsa (0.01s)
    --- PASS: TestRoundTrip/ed25519 (0.00s)
PASS

❯ go test -v ./...                                    
=== RUN   TestFromOpenSSH
=== RUN   TestFromOpenSSH/rsa
    sign_test.go:159: cmd /usr/bin/ssh-keygen -Y sign -n file -f /tmp/TestFromOpenSSH_rsa719251063/001/id /tmp/TestFromOpenSSH_rsa719251063/001/data: Signing file /tmp/TestFromOpenSSH_rsa719251063/001/data
        Write signature to /tmp/TestFromOpenSSH_rsa719251063/001/data.sig
=== RUN   TestFromOpenSSH/ed25519
    sign_test.go:159: cmd /usr/bin/ssh-keygen -Y sign -n file -f /tmp/TestFromOpenSSH_ed255193943236978/001/id /tmp/TestFromOpenSSH_ed255193943236978/001/data: Signing file /tmp/TestFromOpenSSH_ed255193943236978/001/data
        Write signature to /tmp/TestFromOpenSSH_ed255193943236978/001/data.sig
--- PASS: TestFromOpenSSH (0.02s)
    --- PASS: TestFromOpenSSH/rsa (0.01s)
    --- PASS: TestFromOpenSSH/ed25519 (0.01s)
=== RUN   TestToOpenSSH
=== RUN   TestToOpenSSH/rsa
    sign_test.go:223: cmd /usr/bin/ssh-keygen -Y verify -f /tmp/TestToOpenSSH_rsa2114079591/001/allowed_signer -I [email protected] -n file -s /tmp/TestToOpenSSH_rsa2114079591/001/oursig: Good "file" signature for [email protected] with RSA key SHA256:IkDRT/GXJRFrSruMf8F+ilGMaW+kFf2D4quUApK8p6E
    sign_test.go:227: cmd /usr/bin/ssh-keygen -Y verify -f /tmp/TestToOpenSSH_rsa2114079591/001/allowed_signer -I [email protected] -n file -s /tmp/TestToOpenSSH_rsa2114079591/001/oursig: Could not verify signature.
    sign_test.go:232: cmd /usr/bin/ssh-keygen -Y check-novalidate -n file -s /tmp/TestToOpenSSH_rsa2114079591/001/oursig: Signature verification failed: incorrect signature
        Could not verify signature.
=== RUN   TestToOpenSSH/ed25519
    sign_test.go:223: cmd /usr/bin/ssh-keygen -Y verify -f /tmp/TestToOpenSSH_ed25519648723907/001/allowed_signer -I [email protected] -n file -s /tmp/TestToOpenSSH_ed25519648723907/001/oursig: Good "file" signature for [email protected] with ED25519 key SHA256:nTfAQgoE0o29gjmx7bF3pSliPLQ/UVdzeK2QFM4qEw4
    sign_test.go:227: cmd /usr/bin/ssh-keygen -Y verify -f /tmp/TestToOpenSSH_ed25519648723907/001/allowed_signer -I [email protected] -n file -s /tmp/TestToOpenSSH_ed25519648723907/001/oursig: Could not verify signature.
    sign_test.go:232: cmd /usr/bin/ssh-keygen -Y check-novalidate -n file -s /tmp/TestToOpenSSH_ed25519648723907/001/oursig: Signature verification failed: incorrect signature
        Could not verify signature.
--- PASS: TestToOpenSSH (0.06s)
    --- PASS: TestToOpenSSH/rsa (0.03s)
    --- PASS: TestToOpenSSH/ed25519 (0.03s)
=== RUN   TestRoundTrip
=== RUN   TestRoundTrip/rsa
=== RUN   TestRoundTrip/ed25519
--- PASS: TestRoundTrip (0.01s)
    --- PASS: TestRoundTrip/rsa (0.00s)
    --- PASS: TestRoundTrip/ed25519 (0.00s)
PASS

I am new to falco, but is it possible that the first rule matches and that's it? What I am trying to say is that I think it might make sense that the rule gets only triggered alone, because both conditions of the multi-macro has been already triggered. So why triggering that multi macro at all (both parts have been already triggered).

Can you validate this?

- macro: known_exception
  condition: (user.name=root
              and fd.name startswith /etc/falco/rules.d)

- macro: combination_macro
  condition: (known_exception
              and write_etc_common)

- rule: Combination
  desc: Combination Test an attempt to write to any file below /etc
  condition: combination_macro
  output: "Combination below /etc opened for writing (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline parent=%proc.pname pcmdline=%proc.pcmdline file=%fd.name program=%proc.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] container_id=%container.id image=%container.image.repository)"
  priority: ERROR
  tags: [filesystem, mitre_persistence]

Does the above rule work?

mh I looked on this for a while now and I can't see the error as well. Are you sure it's not being logged? I think you forgot at least one line, because I see two errors being thrown for the swap file generated by vi and just one line for the actual file opened by vi. So there is at least one error line missing in your screenshot. Would be interesting to know if that gets thrown or not.

Output of restic version

restic 0.12.0 compiled with go1.15.8 on linux/amd64

What backend/server/service did you use to store the repository?

Configuration via environment variables (worked for years.. now it suddenly breaks with the new restic version):

RESTIC_REPOSITORY="s3:s3.wasabisys.com/<my bucket>"
RESTIC_PASSWORD=<my pw>
AWS_ACCESS_KEY_ID=<access key id>
AWS_SECRET_ACCESS_KEY=<access key>

Command:

$ restic snapshots
Fatal: parsing repository location failed: invalid backend
If the repo is in a local directory, you need to add a `local:` prefix

Expected behavior

Restic should list all snapshots.

Actual behavior

Restic fails to connect to the repository/backend.

Steps to reproduce the behavior

See above

Do you have any idea what may have caused this?

I guess it is version 0.12

Do you have an idea how to solve the issue?

no

Did restic help you today? Did it make you happy in any way?

It made me happy for years :)

found the issue... had something to do with my password manager.. m(

Output of restic version

restic 0.12.0 compiled with go1.15.8 on linux/amd64

What backend/server/service did you use to store the repository?

Configuration via environment variables (worked for years.. now it suddenly breaks with the new restic version):

RESTIC_REPOSITORY="s3:s3.wasabisys.com/<my bucket>"
RESTIC_PASSWORD=<my pw>
AWS_ACCESS_KEY_ID=<access key id>
AWS_SECRET_ACCESS_KEY=<access key>

Command:

$ restic snapshots
Fatal: parsing repository location failed: invalid backend
If the repo is in a local directory, you need to add a `local:` prefix

Expected behavior

Restic should list all snapshots.

Actual behavior

Restic fails to connect to the repository/backend.

Steps to reproduce the behavior

See above

Do you have any idea what may have caused this?

I guess it is version 0.12

Do you have an idea how to solve the issue?

no

Did restic help you today? Did it make you happy in any way?

It made me happy for years :)

@dominikschulz mhhh I am just afraid there is one additional problem. If I use gopass show -n it will also show the Secret: <name> header.. but I only want the content. Is it save to delete this "Secret" header? Will gopass re-add it?