here is my configuration on .env file

This is Solved this Error

your mail.php on config you declare host as smtp.mailgun.org and port is 587 while on env is different. you need to change your mail.php to

if you desire to use mailtrap.Then run this command

env() helper makes the job and there is no need to change values in mail.php. Just ensure that all email settings in .env file are correct

The post Expected response code 250 but got code “530”, with message “530 5.7.1 Authentication required appeared first on scmGalaxy.

Authentication Types in Gerrit explained!

Type of user authentication employed by Gerrit. The supported values are:

By default, OpenID

OpenID
The default setting. Gerrit uses any valid OpenID provider chosen by the end-user. For more information see openid.net.
OpenID_SSO
Supports OpenID from a single provider. There is no registration link, and the “Sign In” link sends the user directly to the provider’s SSO entry point.
HTTP
Gerrit relies upon data presented in the HTTP request. This includes HTTP basic authentication, or some types of commercial single-sign-on solutions. With this setting enabled the authentication must take place in the web server or servlet container, and not from within Gerrit.
HTTP_LDAP
Exactly like HTTP (above), but additionally Gerrit pre-populates a user’s full name and email address based on information obtained from the user’s account object in LDAP. The user’s group membership is also pulled from LDAP, making any LDAP groups that a user is a member of available as groups in Gerrit.
CLIENT_SSL_CERT_LDAP
This authentication type is actually kind of SSO. Gerrit will configure Jetty’s SSL channel to request the client’s SSL certificate. For this authentication to work a Gerrit administrator has to import the root certificate of the trust chain used to issue the client’s certificate into the <review-site>/etc/keystore. After the authentication is done Gerrit will obtain basic user registration (name and email) from LDAP, and some group memberships. Therefore, the “_LDAP” suffix in the name of this authentication type. This authentication type can only be used under hosted daemon mode, and the httpd.listenUrl must use https:// as the protocol. Optionally, certificate revocation list file can be used at <review-site>/etc/crl.pem. For details, see httpd.sslCrl.
LDAP
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
The actual username used in the LDAP simple bind request is the account’s full DN, which is discovered by first querying the directory using either an anonymous request, or the configured ldap.username identity. Gerrit can also use kerberos if ldap.authentication is set to GSSAPI.
LDAP_BIND
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
Unlike LDAP above, the username used to perform the LDAP simple bind request is the exact string supplied in the dialog by the user. The configured ldap.username identity is not used to obtain account information.
OAUTH
OAuth is a protocol that lets external apps request authorization to private details in a user’s account without getting their password. This is preferred over Basic Authentication because tokens can be limited to specific types of data, and can be revoked by users at any time.
Site owners have to register their application before getting started. Note that provider specific plugins must be used with this authentication scheme.
DEVELOPMENT_BECOME_ANY_ACCOUNT
DO NOT USE. Only for use in a development environment.
When this is the configured authentication method a hyperlink titled Become appears in the top right corner of the page, taking the user to a form where they can enter the username of any existing user account, and immediately login as that account, without any authentication taking place. This form of authentication is only useful for the GWT hosted mode shell, where OpenID authentication redirects might be risky to the developer’s host computer, and HTTP authentication is not possible.

Reference
https://dev.vaadin.com/review/Documentation/config-gerrit.html#auth

The post Authentication Types in Gerrit explained! appeared first on scmGalaxy.

HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encrypted communication and secure identification of a network web server. HTTPS connections are often used for payment transactions on the World Wide Web and for sensitive transactions in corporate information systems.

Secure socket layer (SSL): how it works

1.   An SSL certificate enables encryption of sensitive information during online transactions.

2.   Each SSL certificate is a unique credential identifying the certificate owner.

3.   A certificate Authority authenticates the identity of a certificate owner before it is issued.
What is SSL and Certificate

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works.

• A browser requests a secure page (usually https://).
• The web server sends its public key with its certificate.
• The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
• The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
• The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.
• The web server sends back the requested html document and http data encrypted with the symmetric key.
• The browser decrypts the http data and html document using the symmetric key and displays the information.

• A browser attempts to connect to a Web site secured with SSL.

keytool -genkey -alias bf-sandbox -keyalg RSA -keystore buildForgeKeyStore.p12 -keysize 2048

[root@ tmp]# keytool -genkey -alias bf-sandbox -keyalg RSA -keystore buildForgeKeyStore.p12 -keysize 2048
Enter key store password: XXXX
Enter key password for : XXX

You are about to enter information that will be incorporated into
your certificate request.  This information is what is called a
Distinguished Name or DN.  There are quite a few fields but you
can use supplied default values, displayed between brackets, by just
hitting , or blank the field by entering the character
before hitting .

keytool -certreq -sigalg RSA -alias bf-sandbox -file bf-sandbox.csr -keystore buildForgeKeyStore.p1Insallation Certificates in BuildForge

Point 1: You would need to update the bfclient.conf to make Build Forge aware of the certifications. As long as the certificates are in the correct it will work with Build Forge.

Point 2: The easiest way to update the cert would be change the new cert name to the name of the previous cerr. Then update the passwords.

Point 3:
Please use the following command to validate the keystore:

keytool -list -storetype pkcs12 -keystore fullyQualifiedNameOfFile.p12 -v

The Symmetric key

Well, Private Key/Public Key encryption algorithms are great, but they are not usually practical. It is asymmetric because you need the other key pair to decrypt. You can’t use the same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. You must therefore transmit the key to the other party without the enemy getting its hands on it. As you know, nothing is secure on the Internet. The solution is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. You have never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different.

Encryption algorithm:

There are several encryption algorithms available, using symmetric or asymmetric methods, with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had patented his algorithms, then he would have been able to sue Albert Einstein… So algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services. During the negotiation between browser and web server, the applications will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen. OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.

The Hash:

A hash is a number given by a hash function from a message. This is a one way function, it means that it is impossible to get the original message knowing the hash. However the hash will drastically change even for the slightest modification in the message. It is therefore extremely difficult to modify a message while keeping its original hash. It is also called a message digest. Hash functions are used in password mechanisms, in certifying that applications are original (MD5 sum), and in general in ensuring that any message has not been tampered with. It seems that the Internet Enginering Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons (Cf RFC2459 7.1.2 and 7.1.3).

Signing:

Signing a message, means authentifying that you have yourself assured the authenticity of the message (most of the time it means you are the author, but not neccesarily). The message can be a text message, or someone else’s certificate. To sign a message, you create its hash, and then encrypt the hash with your private key, you then add the encrypted hash and your signed certificate with the message. The recipient will recreate the message hash, decrypts the encrypted hash using your well known public key stored in your signed certificate, check that both hash are equals and finally check the certificate.
The other advantage of signing your messages is that you transmit your public key and certificate automatically to all your recipients.
There are usually 2 ways to sign, encapsulating the text message inside the signature (with delimiters), or encoding the message altogether with the signature. This later form is a very simple encryption form as any software can decrypt it if it can read the embedded public key. The advantage of the first form is that the message is human readable allowing any non complaint client to pass the message as is for the user to read, while the second form does not even allow to read part of the message if it has been tampered with.

PassPhrase:

“A passprase is like a password except it is longer”. In the early days passwords on Unix system were limited to 8 characters, so the term passphrase for longer passwords. Longer is the password harder it is to guess. Nowadays Unix systems use MD5 hashes which have no limitation in length of the password.

Public Key Infrastructure

The Public Key Infrastructure (PKI) is the software management system and database system that allows to sign certifcate, keep a list of revoked certificates, distribute public key,… You can usually access it via a website and/or ldap server. There will be also some people checking that you are who you are… For securing individual applications, you can use any well known commercial PKI as their root CA certificate is most likely to be inside your browser/application. The problem is for securing e-mail, either you get a generic type certificate for your e-mail or you must pay about USD100 a year per certificate/e-mail address. There is also no way to find someone’s public key if you have never received a prior e-mail with his certificate (including his public key).

The post Know about Certificates and SSLs appeared first on scmGalaxy.