date:20140913

Bug#610220: Show URLs in TODO/NOTE as hyperlinks in the web view

2014-09-13 Thread Salvatore Bonaccorso

Control: tags -1 - pending

Hi Holger,

On Fri, Sep 12, 2014 at 12:19:06PM +0200, Holger Levsen wrote:
 attached is a patch to lib/python/web_support.py which turns the notes (used 
 in CVEs) into hyperlinks - if they start with http(s)://
 
 Please tell me whether it's ok to commit this.

I had a look at this patch. It can only address isolated URLs in the
notes this way. We usually use this in other ways, one example is that
was Florian mentioned in the first message:

Note: see https://

which should turn into

see a 
href='http://www.example.com/info.html'codehttp://www.example.com/info.html/code/a

Other examples were we use the free form extensively is when we
document which commits introduced a given problem, where fixed, etc:

I'm adding also the corresponding note, as this might change when
looking next time into it:

 - https://security-tracker.debian.org/tracker/CVE-2014-3620

NOTE: http://curl.haxx.se/docs/adv_20140910B.html
NOTE: Introduced by https://github.com/bagder/curl/commit/85b9dc8023

 - https://security-tracker.debian.org/tracker/CVE-2014-3145

NOTE: Upstream fix 
https://git.kernel.org/linus/05ab8f2647e4221cbdb3856dd7d32bd5407316b3
NOTE: Introduced by 
https://git.kernel.org/linus/4738c1db1593687713869fa69e733eebc7b0d6d8
NOTE: 
https://git.kernel.org/linus/d214c7537bbf2f247991fb65b3420b0b3d712c67


 - https://security-tracker.debian.org/tracker/CVE-2014-3122

NOTE: Introduced by 
https://git.kernel.org/linus/b291f000393f5a0b679012b39d79fbc85c018233
NOTE: Fixed by 
https://git.kernel.org/linus/57e68e9cd65b4b8eb4045a1e0d0746458502554c 
(v3.15-rc1)

the last one is particulary interessant as it contains normal text
before, and after a reference which should be turned into a link.

There is one other problematic example with the patch, where we have
notes starting with http(s), but adding explanations/further text
afterwards:

 - https://security-tracker.debian.org/tracker/CVE-2014-6387

NOTE: http://www.mantisbt.org/bugs/view.php?id=17640
NOTE: http://github.com/mantisbt/mantisbt/commit/215968fa8 (1.2.x 
branch)
NOTE: http://github.com/mantisbt/mantisbt/commit/fc02c46ee (master 
branch)

So we would need something more complicated here, isolating first the
urls in the text and converting that part, but keeping the surrounding
ones.

Thanks for also looking into this one!

Regards,
Salvatore


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760900: tagged as pending

2014-09-13 Thread Dmitry Smirnov

On Thu, 11 Sep 2014 20:12:27 Filipus Klutiero wrote:
 Thank you. One more issue persists:
  Libteam provides mechanism to team multiple NICs (ports) into logical one
  (teamdev) at OSI Layer 2 (Data link).
 provides mechanism is incorrect. mechanism is missing a determiner, such
 as a (the sentence could alternatively read Libteam allows several NICs
 (ports) to be grouped into a single logical NIC [...]).

Thanks, updated as advised:


http://anonscm.debian.org/cgit/collab-maint/libteam.git/commit/?id=ab95564b6214336007431051da104fce0dc66051


 By the way, I have never heard about channel teaming. Wikipedia however
 mentions NIC teaming.

Words of upstream from description on home page:

http://libteam.org/

I'm not sure where term channel teaming is used...

-- 
Best wishes,
 Dmitry Smirnov.

---

Much of humankind's intellectual and emotional struggle has been not
for truth, but against truth. The advance of science has been
sporadically fought against for thousands of years.
-- C. W. Dalton, The Right Brain and Religion


signature.asc
Description: This is a digitally signed message part.

Bug#759208: goplay: shows no results at all

2014-09-13 Thread Petter Reinholdtsen

Is there some alternative to goplay/golearn/etc using the package tags
in such a user friendly way?  In other word, should goplay be fixed
for Jessie, or should it just be removed (as will happen automatically
in a few days because of this RC bug)?

I was planning to add goplay to the list of packages installed in
Debian Edu, but stopped when I discovered that it is no longer
working.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761245: icedove: STARTTLS regression: connection to SMTP server was lost in the middle of the transaction

2014-09-13 Thread Carsten Schoenert

On Sat, Sep 13, 2014 at 11:47:07AM +1000, Dmitry Smirnov wrote:
What cipher suite is configured inside the exim configuration?

I'm not sure where to find this information... Whatever cipher settings are
they would be default for Wheezy. As far as I'm aware there were no cipher
customisations on server side.

That may be the problem, as far as I have read the exim package has to be
configured to use ciphers if it get communication via TLS.

I found a arcticle on serverfault.com that gives some background
informations on that and on cipher suites also.
http://serverfault.com/questions/615855/exim-after-thunderbird-update-could-not-negotiate-a-supported-cipher-suite

But I don't know how to exactely configure a exim setup, so I can't give
better hints there. Maybe we should involve the Exim maintainers to. I
add them to the CC list, hopefully they can give some hints there to
look also.

@Andreas Metzler and Marc Haber
Dmitry gets various messages inside the exim log while trying to send
mails from Icedove 31 with enabled TLS.
TLS error on connection from [...]
(gnutls_handshake): Could not negotiate a supported cipher suite.

Looks for me like a missconfigured exim configuration. Can you please
give some useful light for this error message?

Please also read this article to see which cipher suite Mozilla is
supporting
https://wiki.mozilla.org/Security/Server_Side_TLS

Thanks but I know little about TLS and I don't understand how it can be
helpful in my case...

Well, Mozilla has removed the support for weaker cipher suites in
Thunderbird = 31 and I think this plus the exim config together ends in
a not working communication between Icedove and Exim.

What kind of CA you are using? If it is a md5 signature you have to use
an other not md5 hashed certificate.

cacert.org.

Certificate:
Data:
Version: 3 (0x2)
Signature Algorithm: sha512WithRSAEncryption
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)

CaCert was removed from the CA list inside Debian, but this does not
belong to your report I think. Also the signature is not done by md5.

Do you have checked your settings for security.tls.version.min and
security.tls.version.max? The *.min should be 0 and *.max should be 3,
if not your client will not support all version for SSL/TLS.
http://kb.mozillazine.org/Security.tls.version.*

Where are those settings? Anyway I've never touched them...

That's explained on top of the website. ;)
http://kb.mozillazine.org/Editing_configuration

These settings are inside Icedove, you get the configs by Tools –
Options – Advanced – General and press the Config Editor... button

Please play around with the security.tls.version.max option, with a
setting of 1 you say Icedove to explicit use a weak cipher suite.

I strongly believe this report is not a Icedove/Thunderbird related
problem.

I disagree. Otherwise how would you explain why downgrade of icedove fixed
the
problem?
If icedove from Jessie can't talk to SMTP server on Wheezy it is a serious
regression on the client side i.e. in the Icedove.

I agree it's a user regression but you will have a missconfiguration on
the server side I still believe.
I work on various clients with Icedove/Thunderbird =31 against T-Online
(a really big ISP in Germany), Google and a own root server with a
running exim 4.72 without any changes on my Icedove settings. So I
disagree until now this issue a Icedove related. But yes, I could be
wrong.

1 2 3 4 >

1 - 100 of 316 matches

Mail list logo