This is because security team isn't filling core/updates/media_info/descriptions & the like

Component: RPM Packages => Release (media, process)
Source RPM: rpmdrake => (none)
Assignee: bugsquad => qa-bugs
CC: (none) => thierry.vignaud

assigning to sysadmins, as the QA team can do nothing about it yet

Assignee: qa-bugs => sysadmin-bugs

The tools to generate this file still need to be developed.

CC: (none) => boklm

in the main time, is this something that can be filled in manually? by secteam or qateam for instance?

Yes.
I was under impression that was the case back @mdv...

ping for this issue

Any news on this one ?

some users are afraid with the updates...

Source RPM: (none) => rpmdrake

can someone just generate a file on svn that gets put on mirrors and link it to rpmdrake?

perhaps a script that runs in a cronjob on primary mirror that fetches a certain file from svn? something quick & dirty? to just get us going?
maybe something like "svn co svn://.../descriptions" (several times) in a every 5 minute cronjob?

then we can put that in the policy that update maintainer can fill that advisory in that file on svn... and worry about the rest later...

Again this has nothing to do with rpmdrake but with people pushing updates without filling the descriptions file

Source RPM: rpmdrake => (none)

(In reply to comment #9)
> Again this has nothing to do with rpmdrake but with people pushing updates
> without filling the descriptions file

ok sorry

(In reply to comment #9)
> Again this has nothing to do with rpmdrake but with people pushing updates
> without filling the descriptions file

so where do we fill in this info? boklm said the tools didn't exist yet?

rpmdrake is where we see the problem.

iiuc rpmdrake looks for the descriptions file on mirrors?

i did some updates but there is nothing about how to make descriptions for updates?

can anyone tell us what exactly we need to do?

(In reply to comment #11)
> iiuc rpmdrake looks for the descriptions file on mirrors?
> 
> i did some updates but there is nothing about how to make descriptions for
> updates?
> 
> can anyone tell us what exactly we need to do?

Just look at rpmdrake source code, or descriptions file on mandriva mirrors.

(In reply to comment #12)
> (In reply to comment #11)
> > iiuc rpmdrake looks for the descriptions file on mirrors?
> > 
> > i did some updates but there is nothing about how to make descriptions for
> > updates?
> > 
> > can anyone tell us what exactly we need to do?
> 
> Just look at rpmdrake source code, or descriptions file on mandriva mirrors.

i meant, what file do we need to adjust? i don't think we have direct access to primary mirror?

*** Bug 2823 has been marked as a duplicate of this bug. ***

CC: (none) => marcello.anni

Any chance to fix this bug for mga 2 ? should we update the updates_policy ?

hope so, with mageia 2 the project reaches a mature status, it would be a shame to not have this feature...

Saying that it's a shame something is not yet done does not really help getting it done ...

so, afaik, we need to change in the updates policy:

- for people who push the update, (is that sysadmin?)
- after they push the update and sending email,
- change the descriptions file (where? is there an svn location that gets propagated to the primary mirror for this?)

does anyone have any objections for me to put this in the updates policy?

This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad

What we have in advisory files:

type: security
subject: Updated kernel packages fix security vulnerabilities
CVE:
 - CVE-2042-1
src:
  42:
   core:
     - kernel-42.42.42-1.mga42
description: |
  This kernel update is based on upstream -longterm 42.42.42 and
  fixes the following security issues:
  [...]
references:
 - https://bugs.mageia.org/show_bug.cgi?id=424242
 - https://www.kernel.org/pub/linux/kernel/v42.x/ChangeLog-42.42.42
ID: MGASA-2042-0002

What rpmdrake wants for each package:

{importance} which is 'bugfix', 'security' or 'normal'
{pre} which is the reason for the update
optionaly {description} which is the rpm description, but it's only a fallback if we don't have it from the package

So it shouldn't be too hard to generate the file, putting 'type' into 'importance' and 'description' + maybe 'references' into 'pre'

CC: (none) => pterjan

hmm Pascal, according to get_updates_description in urpm module iiuc it should be
called descriptions.
and here http://advisories.mageia.org/ we have almost all the relevant 
information.
Could that file compiled automatically when mageia advisory is compiled by
some magical and automatic tool?

Yes, my previous comment explains what the tool should do to map the information we have in advisories to what is expected to be in "descriptions" file :)

another approach could be to improve http://gitweb.mageia.org/software/infrastructure/mgaadvisories/
to be not only a tool but a module to be used to extract advisory and used
in new rpm tool at that aim also. Don't know if it is possible though

I had started adding the code into it (but didn't get very far).

well listadv seems very near to the scope, if the db had package version also 
we could get that info by calling something like
MGA::Advisories::listadv(source_pkg, version) and get the advisory
removing the print of course ;)
Note that in the advisory (qt for instance) it seems we add
info such as srpms and version:
SRPMS:
- 4/core/qt3-3.3.8b-33.3.mga4
- 4/core/qt4-4.8.6-1.2.mga4
- 4/core/qtbase5-5.2.0-2.4.mga4
So it should be easy to make them available by a query i believe.


But i found also another problem by following that way
because when we look for advisory we know the binary package name and URPM::Package seems not to say which is the source name of it:
DB<22> l
327==>      push @$s, get_advisory_link($update_descr) if $is_update;
[...]
DB<23> x $name
0  'lib64qtcore4'
  DB<24> x $pkg->{pkg}
0  URPM::Package=SCALAR(0xe56be20)
   -> 240571936
  DB<25> x $pkg->{pkg}->sourcerpm
  empty array
^^^^^^^^^^^ Why empty array?

  DB<26> x $pkg->{pkg}->version
0  '4.8.6'
  DB<27> x $pkg->{pkg}->release
0  '1.2.mga4'

have i missed anything?
and could be this way a possible solution?

->sourcerpm() only works if the URPM object has a RPM header attached.

It hasn't if it cames from parsing synthesis b/c there's no header in synthesis (that's the difference with huge hdlists) and not that info, ...

It has one if it comes from parsing hdlist, a rpm file, a spec file or when traversing rpmdb.

ie when calling one of parse_hdlist() parse_rpm(), spec2srcheader(), traverse*() or also update_header() & stream2header()


Where's the code you're talking about?
We may just get the media path then the package path and they create a new URPM object and query it.

Ah you mean you want rpmdrake to lookup the SRPM...
Then we would need to put the whole generatea package in 'descriptions' list like in the old days
eg: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/official/updates/2010.0/x86_64/media/media_info/descriptions

Did anyone asked Oden if it was somewhat automated in mdv days?

Yes description is a possibility, when writing the advisory.
OTOH we could ask to advisory db directly since
we could improve the api here:
http://gitweb.mageia.org/software/infrastructure/mgaadvisories/
and use them into the rpm tool when a package is selected.

I was intending to add code to mgaadvisories to generate descriptions file when moving packages, as it has all the information.

on comment#28 yes Oden confirm it's automatic.

I have something more or less working but have several problems (including not being able to test).

One strange thing is that the file lists packages without version so there is no way to know which ones apply to a specific update:

ftp://ftp.mirrorservice.org/sites/carroll.cac.psu.edu/MandrivaLinux/official/2011/i586/media/media_info/descriptions

Reading urpm::get_updates_description, it will overwrite when reading the file so just use the latest one for each package.

(I guess you will not see that there was a security update before if it is followed by a bugfix, but I have failed to use rpmdrake for the last hour so have no idea how the UI look like anyway).

urpmq --auto-select -i seems happy with my file:

Name        : git-core-oldies
Version     : 1.8.5.6
Release     : 1.mga4
Group       : Development/Other
Size        : 0                            Architecture: x86_64
Source RPM  : git-1.8.5.6-1.mga4.src.rpm     Build Host: ecosse.mageia.org
Packager    : luigiwalser <luigiwalser>
URL         : http://git-scm.com/
Summary     : Git obsolete commands, bound to extinction
Description :
Git obsolete commands, bound to extinction
Update importance   : security
Reason for update   :
It was reported that git, when used as a client on a case-insensitive
filesystem, could allow the overwrite of the .git/config file when the client
performed a "git pull".  Because git permitted committing .Git/config (or any
case variation), on the pull this would replace the user's .git/config.  If
this malicious config file contained defined external commands (such as for
invoking and editor or an external diff utility) it could allow for the
execution of arbitrary code with the privileges of the user running the git
client (CVE-2014-9390).

References:
- https://bugs.mageia.org/show_bug.cgi?id=14849
- http://article.gmane.org/gmane.linux.kernel/1853266
- https://bugzilla.redhat.com/show_bug.cgi?id=1175960

maybe we can extend the descriptions to allow for this, so that multiple fixes could be aggregated by the program reading it? (ie: urpmi, rpmdrake and manadrake)

urpmi doesn't use them, those desc were introduced for MgaUpdate, then urpmq started using them in:
http://gitweb.mageia.org/software/rpm/urpmi/commit/urpm.pm?id=81b3d92b9f72ed5e66d

Then code was then factored in urpm.pm for both rpmdrake & urpmq:
http://gitweb.mageia.org/software/rpm/urpmi/log/urpm.pm?qt=grep&q=description
http://gitweb.mageia.org/software/rpmdrake/commit/Rpmdrake?id=add972b102e4d2d75

So it should be possible to keep package versions, then alter rpmdrake to look at all the update descriptions, keep the most urging category & display all update descriptions.

That's another subject & would be for mga6 though since here we're just restoring previous behavior

Also Pascal, previously we kept all updates in descriptions, not just latest one.

They are all in descriptions, but the code reading it will only keep the latest as it's a hash keyed on the name and the value get overwritten each time we see another update with same package name.

I agree it's not the right time to change how things work, I'll just finish generating the file like it used to be.

Agree as well. 

If Pascal has fixed this restoring most of the old behavior, i would release it though. We can then open a new bug to develop at the best this functionality for mga6 and maybe move all the relative bugs that could follow the release to the new one.

I looked at the code again, main problem is to find which media need their descriptions updated as the advisory only lists distrib/media/src.rpm but not architecture.
I guess I'll just do it for all architectures by using a glob.

Hi Pascal. Do you think you'll be able to do it before Mageia 6 and that I can thus add Mageia 6 as milestone?

I can try, I just need to find where is my half working code :)

Hi,
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.

Status?

CC: (none) => fri

we still not have the tool.

Thierry can you provide some informations ? 
we can fix this during mageia 8 lifetime. ( can or must :-) )


Pascal have you found your half working code ?

CC: (none) => mageia