Bug 883301 - notifier.conf: MAIL_PASSWORD= <value containing &> is refered to as empty, and fail notifier service start
Summary: notifier.conf: MAIL_PASSWORD= <value containing &> is refered to as empty, an...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-notification-service
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 3.2.0
Assignee: Noam Slomianko
QA Contact: Ilanit Stein
URL:
Whiteboard: infra
Depends On:
Blocks: 915537
TreeView+ depends on / blocked
 
Reported: 2012-12-04 09:28 UTC by Ilanit Stein
Modified: 2016-02-10 19:19 UTC (History)
10 users (show)

Fixed In Version: sf8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 10704 0 None None None Never

Description Ilanit Stein 2012-12-04 09:28:58 UTC
Description of problem:

Using '&' in MAIL_PASSWORD, give same failure, as if it was empty.

When using the following settings in notifier.conf:
MAIL_USER=istein, MAIL_ENABLE_SSL=true, MAIL_PASSWORD=&
restartting notifier service fail on:
Error: $MAIL_PASSWORD is not defined for SSL MAIL, please check for this in configuration file /etc/ovirt-engine/notifier/notifier.conf

Version-Release number of selected component (if applicable):
SI24.5

How reproducible:
always

Expected results:
Have the '&' a valid charachter for MAIL_PASSWORD.

Comment 1 Simon Grinberg 2012-12-25 11:10:07 UTC
Ilanit, does this happen for any password containing this character? in any length? 

If it only happens if password is a single & character I would close as not fix, this password hardly if ever be found in a real life use case. Not worth the fix.

Comment 2 Yaniv Kaul 2012-12-25 11:13:50 UTC
(In reply to comment #1)
> If it only happens if password is a single & character I would close as not
> fix, this password hardly if ever be found in a real life use case. Not
> worth the fix.

We were specifically asked in the past to support chars such as !@#$%^&*() 
We had bugs from customers where they were not supported.

Comment 3 Ilanit Stein 2012-12-26 08:11:45 UTC
This happen for any password containing this character. At any length.

Comment 4 Simon Grinberg 2012-12-30 10:02:37 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > If it only happens if password is a single & character I would close as not
> > fix, this password hardly if ever be found in a real life use case. Not
> > worth the fix.
> 
> We were specifically asked in the past to support chars such as !@#$%^&*() 
> We had bugs from customers where they were not supported.

Agree, no problem with that, I was only wandering if it's just an issue with a password with length of one character. At any length as mentioned in comment #3 then it's a bug that needs fixing.

Comment 5 Ilanit Stein 2013-02-28 12:37:24 UTC
Verified on sf-8

Comment 6 Itamar Heim 2013-06-11 08:22:45 UTC
3.2 has been released

Comment 7 Itamar Heim 2013-06-11 08:24:56 UTC
3.2 has been released


Note You need to log in before you can comment on or make changes to this bug.