Here is what I came up with, if this seems to make sense and is
considered as a patch, *please do proofread and test it, I did no
such thing on my end.*
One small remark: the "+" after ssl_key and ssl_cert (lines 122+123)
mean "match one or more of the last character". Thus, a config line like
On 01/14/2013 03:10 PM, Jaldhar H. Vyas wrote:
So what we really need is more testing before an upload even happens.
In theory there is a team maintaining this package but in practice the
others have even less free time than I do and this last year I have
had next to no time at all. (I mean i
On 01/23/2013 03:10 PM, Herwin Weststrate wrote:
Here is what I came up with, if this seems to make sense and is
considered as a patch, *please do proofread and test it, I did no
such thing on my end.*
One small remark: the "+" after ssl_key and ssl_cert (lines 122+123)
mean "match one or more
Sorry for not responding sooner I was unexpectedly swamped during the new
year.
On Fri, 28 Dec 2012, Dominik George wrote:
The breakage is even worse.
1. The code that causes the problem is intended to set the *new*
path to the certificates. Why the f*** does it print $OLD_SSL_CERT ??
No
On Mon, 31 Dec 2012, Ian Zimmerman wrote:
Ob-content: this looks like a rerun of #644121.
That one got closed without ever getting resolved didn't it? I don't
think it is the same problem because all the configuration files are
protected by dpkg's upgrade mechanisms. The certificate stuff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
> If I'm following the logic correctly then that would change to $SSL_CERT and
> $SSL_KEY while these will never be generated.
> And I'm still trying to figure out why that whole block of code exists..
That's what I was actually saying.
It mak
Me too :-P
Ob-content: this looks like a rerun of #644121.
--
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave
-if (/^\w*?ssl_cert/) {
-say 'ssl_cert = <$OLD_SSL_CERT'
+if (m|^\w*?ssl_cert\s*=\s*<$OLD_SSL_CERT|) {
+say 'ssl_cert = <$SSL_CERT'
}
-elsif (/^\w*?ssl_key/) {
-say 'ssl_key = <$OLD_SSL_KEY'
+elsif (m|^\w*?ssl_key\s*=\s*
Package: dovecot-core
Version: 1:2.1.7-6
Followup-For: Bug #696817
Control: tags -1 + patch
The breakage is even worse.
1. The code that causes the problem is intended to set the *new*
path to the certificates. Why the f*** does it print $OLD_SSL_CERT ??
2. NEVER EVER touch user confiuration!
Yes, I just hit this problem too.
My config was pointing to my own certificate and was changed to point to
the self-signed cetificate.
I'm not quite sure what is the intended purpose of the following code in
postinst?
OLD_SSL_CERT="/etc/ssl/certs/dovecot.pem"
OLD_SSL_KEY="/etc/ssl/priva
Package: dovecot-core
Version: 1:2.1.7-6
Severity: serious
Before upgrade I had
ssl_cert =
ii dovecot-sqlite1:2.1.7-6
ii ntp 1:4.2.6.p5+dfsg-2
Versions of packages dovecot-core is related to:
ii dovecot-common 1:2.1.7-6
ii dovecot-core [dovecot-comm
11 matches
Mail list logo
