Add Release Bundle exists API

[oshratZairi]

… RBV2.

• All tests passed. If this feature is not already covered by the tests, I added new tests.
• All static analysis checks passed.
• This pull request is on the dev branch.
• I used gofmt for formatting the code before submitting the pull request.

---

Implemented a new API endpoint to check if a release bundle exists in RBV2

[EyalDelarea]

I got a little confused if this is a check for RBV1 / V2 check, Or endpoint to check weather a release bundle exists. ( maybe it's the same meaning but i got confused )

This also effect the location of the code, if it should be on v1 or v2.
And also the name of the function, IsRV2? \ exists?

Can we clarify what is the use case and name the functions to be more clear?

[EyalDelarea]

As this is a lifecycle endpoint, And RBV2 is under "lifecycle", let's move the relevant code to lifecycle-services.

It is indeed confusing because this is the code for V1.

[EyalDelarea]

Once we transition to the V2 code, we should no longer need to manually remove the Artifactory endpoint; we can simply append the new endpoint.

[EyalDelarea]

Looks good!

Please let's edit the function call & filename, and then update the README and explain each parameter even if it seems self explanatory.

[EyalDelarea]

Can we change this to releaseBundleExists(projectName,rbName,rbVersion)?

Once it's done, update the readme with a detailed example for each parameter.

Afterward the call will look like this:

exists, err := serviceManager.releaseBundleExists(projectName,rbName,rbVersion)

[EyalDelarea]

Suggested change

	- [Check if Release Bundle exists in V2](#check-if-rb-exists-in-v2)
	- [Check if Release Bundle exists ](#check-rb-exists)

[EyalDelarea]

Since projectName is optional, let change it to rbName,rbVersion,projectName

[EyalDelarea]

Please let's add a comment explaining that project is optional and can be empty.

[EyalDelarea]

Waiting for the CLI PR to be ready to merge.

[github-actions]

📗 Scan Summary

• Frogbot scanned for vulnerabilities and found 1 issues

Scan Category	Status	Security Issues
Software Composition Analysis	✅ Done	Not Found
Contextual Analysis	✅ Done	-
Static Application Security Testing (SAST)	✅ Done	1 Issues Found 1 Low
Secrets	✅ Done	-
Infrastructure as Code (IaC)	✅ Done	Not Found

---

🐸 JFrog Frogbot

[github-actions]

{
		User: "admin",
		Auth: []ssh.AuthMethod{
			sshAuth,
		},
		//#nosec G106 -- Used to get ssh headers only.
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
	}

at auth/sshlogin.go (line 67)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	SSH key not verified properly, expired certificates may be accepted

Full description

Vulnerability Details

CWE:	322
Rule ID:	go-key-past-expiration

Overview

SSH Keys Past Expiration is a vulnerability that occurs when SSH keys
used for authentication have expired. Expired keys can lead to
unauthorized access to systems and sensitive data, posing a security
risk to the organization.

Vulnerable example

package main

import (
    "golang.org/x/crypto/ssh"
    "net"
)

func main() {}

func insecureIgnoreHostKey() {
    _ = &ssh.ClientConfig{
        User:            "username",
        Auth:            []ssh.AuthMethod{nil},
        HostKeyCallback: ssh.InsecureIgnoreHostKey(),
    }
}

In this example, the InsecureIgnoreHostKey function is used to ignore
host key verification, which can lead to accepting expired or invalid
keys.

Remediation

package main

import (
    "golang.org/x/crypto/ssh"
    "net"
)

func main() {}

func secureHostKeyCallback() {
    publicKeyBytes, _ := ioutil.ReadFile("allowed_hostkey.pub")
    publicKey, _ := ssh.ParsePublicKey(publicKeyBytes)

    _ = &ssh.ClientConfig{
        User:            "username",
        Auth:            []ssh.AuthMethod{nil},
        HostKeyCallback: ssh.FixedHostKey(publicKey),
    }
}

By using allowed host keys and proper host key verification, we can
mitigate the risk of accepting expired or invalid SSH keys.

---

🐸 JFrog Frogbot