Re: Wheezy/ELTS samba update broken for i386 arch
Hi,
On 10/04/2019 13:00, john wrote:
> Hi,
> Samba update for ELTS is broken on i386 arch as some packages remain
> at old version and therefore there are broken dependencies:
>
> # aptitude -V install samba samba-common samba-common-bin tdb-tools
> The following NEW packages will be installed:
> libtalloc2{a} [2.0.7+git20120207-1] libtdb1{a} [1.2.10-2]
> libwbclient0{a} [2:3.6.6-6+deb7u17] samba{b} [2:3.6.6-6+deb7u17]
> samba-common [2:3.6.6-6+deb7u19] samba-common-bin [2:3.6.6-6+deb7u17]
> tdb-tools [1.2.10-2]
> 0 packages upgraded, 7 newly installed, 0 to remove and 1 not upgraded.
> Need to get 8,598 kB/8,663 kB of archives. After unpacking 43.9 MB
> will be used.
> The following packages have unmet dependencies:
> samba : Depends: samba-common (= 2:3.6.6-6+deb7u17) but
> 2:3.6.6-6+deb7u19 is to be installed.
> The following actions will resolve these dependencies:
>
> Keep the following packages at their current version:
> 1) samba [Not Installed]
>
>
>
>
>
> AMD64 arch looks fine:
>
> # aptitude -V install samba samba-common samba-common-bin tdb-tools
> The following NEW packages will be installed:
> libfile-copy-recursive-perl{a} [0.38-1] libtalloc2{a}
> [2.0.7+git20120207-1] libtdb1{a} [1.2.10-2] libwbclient0{a}
> [2:3.6.6-6+deb7u19] samba [2:3.6.6-6+deb7u19] samba-common
> [2:3.6.6-6+deb7u19] samba-common-bin [2:3.6.6-6+deb7u19] tdb-tools
> [1.2.10-2] update-inetd{a} [4.43]
> 0 packages upgraded, 9 newly installed, 0 to remove and 4 not upgraded.
AFAICS the u19 update for pushed for amd64 but not for i386 (yet?).
Mike?
Cheers!
Sylvain Beucler
Debian LTS
Re: jessie-updates gone
Le mer. 10 avr. 2019 à 13:24, Emilio Pozuelo Monfort a écrit : > > JFTR, jessie-updates is back. > Thanks !
Re: LTS, no-dsa reasoning and sponsored packages
Hi Sylvain, On Mon, Apr 08, 2019 at 10:18:08PM +0200, Sylvain Beucler wrote: > Hi, > > On 08/04/2019 21:56, Holger Levsen wrote: > > On Mon, Apr 08, 2019 at 09:51:19PM +0200, Salvatore Bonaccorso wrote: > >> Recently I noticed that for a no-dsa (either for no-dsa or the > >> stronger ignored) as explanation was started to be used e.g. "not used > >> by any sponsor". > > That sounds related to my triage of libpodofo today. It was at least the trigger for my mail ;-) > Firstly, as an aside, it seemed to me that was not stronger, > but more precise than (a "sub-state" as documented at > https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory > ). > Let me know if you prefer we use Yep I know about the sub-state distinction. What I meant with stronger can maybe been illustrated as follows: while a issue marked as no-dsa might be reconsidered, postponed defintively to be looked at at next update we want to have for a specific source package, ignored is stronger in the sense, we likely are going not to look at this anymore from security team point of view (well one can always reconsider, but let's say that is the intetion at the point when someone adds the entry in the list for specific CVE and suite). Does not mean cannot be fixed, but somehow goes down on the radar. Anyway, but that was not the main point. I raised the concern about the 'not used by any sponsors' part. Using the appropriate substate as needed is fine, so whatever it will be for the respective entry, either no-dsa, postponed or ignored for the respective triage. > >> If LTS is meant as Debian project, then I would suggest not to start > >> to use those formulations, which I think are fine for ELTS, which is a > >> dedicated project not on Debian directly. Saying something is not DSA > >> worthy or is going to be ignored, because it's not used by a LTS > >> sponsor will give a signal to others that indeed, Debian LTS is not a > >> generic Debian project. > > thanks for bringing this up. FWIW, I agree with you. > Secondly, being my first go at triaging, I looked at past triages, and > the first occurrence of "not used by any sponsor" is from last August, > so I believed that was a good reason to document it as an additional > reason (the main reason being it's a caught exception / basic DoS, not a > crash with memory overwrite & cie, plus a low popcon for Jessie). > > But I'll leave that out from now on. > > > >> Just stick to "Minor issue" in such cases if something is not DSA > >> worthy because the issue is minor, but do not make it depdendent on if > >> a paying LTS sponsor is using it or not. > > (or dont mark it "Minor issue" if it's not minor. This should also > > hopefully make it more likely someone picks it up as a volunteer efford, > > eg when proofing one is captable of lts work...) > > FWIW I like when we justify why it is minor. Sure, I really wanted to hilight the 'not used by any sponsor' part. It is perfectly fine to write more there, not just minor issue, and give some concise reasoning on why something is no-dsa, ignored or postponed. Just try to keep it coincise (or other worded not let it become a novel). Hope this helps, Regards, Salvatore
Re: jessie-updates gone
On 26/03/2019 11:08, Jakob Hirsch wrote: > Hi, > > so I noticed this morning that jessie-updates is gone from the mirrors. > After some research, I found that this was kind of announced in > https://lists.debian.org/debian-devel-announce/2019/03/msg6.html. > Question is now, what should I put in my sources.list? I used > https://wiki.debian.org/LTS/Using#Using_Debian_Long_Term_Support_.28LTS.29 > as the authorative source, but this is obviously outdated now. > > So, am I ok by just using these two? > > deb http://deb.debian.org/debian/ jessie main contrib non-free > deb http://security.debian.org/ jessie/updates main contrib non-free JFTR, jessie-updates is back. Cheers, Emilio
Re: LTS, no-dsa reasoning
On 10/04/2019 12:50, Sylvain Beucler wrote: > Hi Salvatore, > > On 08/04/2019 22:18, Sylvain Beucler wrote: >> On 08/04/2019 21:56, Holger Levsen wrote: >>> On Mon, Apr 08, 2019 at 09:51:19PM +0200, Salvatore Bonaccorso wrote: Recently I noticed that for a no-dsa (either for no-dsa or the stronger ignored) as explanation was started to be used e.g. "not used by any sponsor". >> Firstly, as an aside, it seemed to me that was not stronger, >> but more precise than (a "sub-state" as documented at >> https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory >> ). >> Let me know if you prefer we use > > Ping? :) It depends on the case. ignored is indeed more precise than no-dsa, because a no-dsa issue can be fixed later (i.e. postponed). However the problem here wasn't really the ignored vs postponed vs no-dsa tag, but the sponsorship note. I agree with Salvatore here. An issue should be triaged as no-dsa (or any substate) based on its own merits, i.e. ease of exploitation, code execution, remote attack, etc. The sponsorship status is irrelevant there and doesn't really add any meaningful information. Cheers, Emilio
Wheezy/ELTS samba update broken for i386 arch
Hi,
Samba update for ELTS is broken on i386 arch as some packages remain at
old version and therefore there are broken dependencies:
# aptitude -V install samba samba-common samba-common-bin tdb-tools
The following NEW packages will be installed:
libtalloc2{a} [2.0.7+git20120207-1] libtdb1{a} [1.2.10-2]
libwbclient0{a} [2:3.6.6-6+deb7u17] samba{b} [2:3.6.6-6+deb7u17]
samba-common [2:3.6.6-6+deb7u19] samba-common-bin [2:3.6.6-6+deb7u17]
tdb-tools [1.2.10-2]
0 packages upgraded, 7 newly installed, 0 to remove and 1 not upgraded.
Need to get 8,598 kB/8,663 kB of archives. After unpacking 43.9 MB will be
used.
The following packages have unmet dependencies:
samba : Depends: samba-common (= 2:3.6.6-6+deb7u17) but 2:3.6.6-6+deb7u19
is to be installed.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) samba [Not Installed]
AMD64 arch looks fine:
# aptitude -V install samba samba-common samba-common-bin tdb-tools
The following NEW packages will be installed:
libfile-copy-recursive-perl{a} [0.38-1] libtalloc2{a}
[2.0.7+git20120207-1] libtdb1{a} [1.2.10-2] libwbclient0{a}
[2:3.6.6-6+deb7u19] samba [2:3.6.6-6+deb7u19] samba-common
[2:3.6.6-6+deb7u19] samba-common-bin [2:3.6.6-6+deb7u19] tdb-tools
[1.2.10-2] update-inetd{a} [4.43]
0 packages upgraded, 9 newly installed, 0 to remove and 4 not upgraded.
Cheers
john
Re: LTS, no-dsa reasoning
Hi Salvatore, On 08/04/2019 22:18, Sylvain Beucler wrote: > On 08/04/2019 21:56, Holger Levsen wrote: >> On Mon, Apr 08, 2019 at 09:51:19PM +0200, Salvatore Bonaccorso wrote: >>> Recently I noticed that for a no-dsa (either for no-dsa or the >>> stronger ignored) as explanation was started to be used e.g. "not used >>> by any sponsor". > Firstly, as an aside, it seemed to me that was not stronger, > but more precise than (a "sub-state" as documented at > https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory > ). > Let me know if you prefer we use Ping? :) - Sylvain
(E)LTS report for March
Hi, During the month of March, I spent 26 hours working on LTS on the following tasks: libsndfile security update prepared firmware-nonfree update ntfs-3g security update firefox-esr security updates bash security update ghostscript coordination openjdk-7 security update drupal7 security update thunderbird security update tzdata, libdatetime-timezone-perl updates CVE triaging I also spent 16h on ELTS: - openjdk-7 security update - security tracker improvements (pre-commit hook) - libsndfile security update - firmware-nonfree update (not yet released) - ntfs-3g security update - bash security update - tiff3 review / feedback - tzdata, libdatetime-timezone-perl updates - CVE triaging Cheers, Emilio
