https://bugzilla.novell.com/show_bug.cgi?id=820566https://bugzilla.novell.com/show_bug.cgi?id=820566#c0
Summary: wireshark security updates to 1.8.7 and 1.6.15
Classification: openSUSE
Product: openSUSE 12.3
Version: Final
Platform: All
OS/Version: openSUSE 12.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Security
AssignedTo: security-team(a)suse.de
ReportedBy: Andreas.Stieger(a)gmx.de
QAContact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101
Firefox/20.0
https://www.wireshark.org/docs/relnotes/wireshark-1.8.7.html
wnpa-sec-2013-23
CVE-2013-2486
CVE-2013-2487
The RELOAD dissector could go into an infinite loop.
wnpa-sec-2013-24
The GTPv2 dissector could crash.
wnpa-sec-2013-25
The ASN.1 BER dissector could crash.
wnpa-sec-2013-26
The PPP CCP dissector could crash.
wnpa-sec-2013-27
The DCP ETSI dissector could crash.
wnpa-sec-2013-28
The MPEG DSM-CC dissector could crash.
wnpa-sec-2013-29
The Websocket dissector could crash.
wnpa-sec-2013-30
The MySQL dissector could go into an infinite loop.
wnpa-sec-2013-31
The ETCH dissector could go into a large loop.
https://www.wireshark.org/docs/relnotes/wireshark-1.6.15.html
1.6.15
wnpa-sec-2013-25
The ASN.1 BER dissector could crash
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=800701https://bugzilla.novell.com/show_bug.cgi?id=800701#c0
Summary: X windows is corrupt after logging in on an AMD
A10-5800K APU
Classification: openSUSE
Product: openSUSE Factory
Version: 12.3 Beta 1
Platform: x86-64
OS/Version: Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Xen
AssignedTo: jdouglas(a)suse.com
ReportedBy: ajbiii(a)comcast.net
QAContact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101
Firefox/7.0.1
Installed 12.3. The regular kernel and X windows works fine. Reboot to the
xen kernel. The login screen is displayed correctly. After logging in, the
display is corrupt. The mouse pointer is ok and I can see that the menu is
active by putting the cursor in the lower left corner and clicking but the
display is unusable.
Just an aside: The xen kernel wouldn't even boot on the APU with 12.1 or 12.2.
Reproducible: Always
Steps to Reproduce:
1. Install 12.3 on an AMD Trinity APU.
2. Boot regular kernel, log in and verify X is working.
3. Reboot with the xen kernel.
4. Log in and observe the corruption
Actual Results:
Screen is corrupt
Expected Results:
Normal X windows operation
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=879402https://bugzilla.novell.com/show_bug.cgi?id=879402#c0
Summary: date format of atq is unusable for sorting
Classification: openSUSE
Product: openSUSE 13.1
Version: Final
Platform: x86-64
OS/Version: openSUSE 13.1
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: martin(a)oneiros.de
QAContact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101
Firefox/29.0
The atq in 13.1 uses a date/time format that is unsuitable for sorting by
date/time and there is no way to set the date format used (e.g. to ISO8601).
Reproducible: Always
Steps to Reproduce:
1. Set up some jobs with at
2. Run atq
Actual Results:
> atq
1377 Thu May 29 15:04:00 2014 a ms
1387 Thu May 22 21:59:00 2014 a ms
1376 Thu May 29 18:39:00 2014 a ms
1372 Wed May 28 21:32:00 2014 a ms
1 Fri May 23 21:04:00 2014 a ms
1361 Sun May 25 08:04:00 2014 a ms
1373 Thu May 29 09:29:00 2014 a ms
1367 Tue May 27 20:02:00 2014 a ms
4 Fri May 23 22:03:00 2014 a ms
1369 Wed May 28 21:04:00 2014 a ms
7 Sat May 24 19:04:00 2014 a ms
10 Sat May 24 23:03:00 2014 a ms
Expected Results:
The date format should be ISO 8601 - or there should be a switch to set the
date format used.
The atq up to 12.3 used ISO 8601, so this is a regression.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612075
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=892893https://bugzilla.novell.com/show_bug.cgi?id=892893#c0
Summary: Unable to Configure NFS Server a Reboot is Required
Classification: openSUSE
Product: openSUSE 13.1
Version: Final
Platform: x86-64
OS/Version: openSUSE 13.1
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
AssignedTo: yast2-maintainers(a)suse.de
ReportedBy: secure(a)aphofis.com
QAContact: jsrain(a)suse.com
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Firefox/31.0
Enter
Yast>Network Services>NFS Server>
Start Services, Open Firewall, Disable NFSv4, Export 2 Directories>Finish
ERROR
Unable to stop idmapd.
Reproducible: Always
Steps to Reproduce:
1.Enter
Yast>Network Services>NFS Server>
Start Services, Open Firewall, Disable NFSv4, Export 2 Directories>Finish
ERROR
Unable to stop idmapd.
2.
3.
Actual Results:
ERROR
Unable to stop idmapd.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=869116https://bugzilla.novell.com/show_bug.cgi?id=869116#c0
Summary: Apper No Longer Requires escalation to root auth to
make changes to installing O/S changes
Classification: openSUSE
Product: openSUSE 12.3
Version: Final
Platform: x86-64
OS/Version: openSUSE 12.3
Status: NEW
Severity: Major
Priority: P5 - None
Component: Security
AssignedTo: security-team(a)suse.de
ReportedBy: secure(a)aphofis.com
QAContact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101
Firefox/27.0
Apper in its now current for will not call for escalation to root authority to
modify and install changes to O/S.
If we wanted to copy MS convention where updates and changes to the O/S....we
would use it. This is one of the stand-out security features thats sets our O/S
above the rest and to enable these changes without root authority sets a
dangerous precedent
Reproducible: Always
Steps to Reproduce:
1. Every time apper wants to make changes to the O/S 100% reproducable
2.
3.
Actual Results:
No escalation to root authority is called by apper
Expected Results:
Changes to O/S should be the privilege of root and no user authority and
escalation to root should be called for before we let any application change
the O/S
With so much log data files I don’t really no what to supply to support
this...Please provide details of what audit log files you require to solve.
Priority set as this is a direct threat to O/S security and its now broken as
previously root auth was always required.
Please do not close as DOWNSTREAM OR UPSTREAM..Apper is an integral and non
optional inclusion to the packing list of 12.3 and as such the product opensuse
is the arbiter and coordinator of Apper
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=848914https://bugzilla.novell.com/show_bug.cgi?id=848914#c0
Summary: Publish Information around Partitioning Requirements
of Boot Requirements with UEFI BIOS
Classification: openSUSE
Product: openSUSE 12.3
Version: Final
Platform: x86-64
OS/Version: openSUSE 12.3
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: Installation
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: secure(a)aphofis.com
QAContact: jsrain(a)suse.com
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Firefox/24.0
If ever we are going to see changed in PC BIOS's it will be in this decade.
Current UEFI BIOS's are standard with most all X_64 Motherboards. The UEFI BIOS
is a temporary measure to permit backwardly compatible Processors and
Motherboards and my enhancement would be to publish partitioning information on
screen thats not an option before the partitioning phase of Installation.
Current warnings generated by the Partitioner itself do warn of requirements
for /boot/uefi with FAT.
As there will be many changes to BIOS this decade I think we need a mandatory
full screen explanation of partitioning changes that can be written for all
coming versions as it will be needed and under that preface every installation
from 13.x to anything can all make use of a text screen before the partitioner
is displayed on screen as part of every Installation
Reproducible: Always
Steps to Reproduce:
1. Try to configure a boot partition with an X_64 UEFI BIOS and a warning is
generated on the users final acceptance of the chosen partitioning.
2. The warning is too late and there is not sufficient space to provide
detailed instructions and the reasoning and its going to get more problematic.
Additionally as soon as M.S come out with a new file formation partitioning we
will need to spell partitioning out in a clear concise way before the user does
anything with the partitioner
3.
Expected Results:
Its a small and advantages addition to the Install Program to have a text
screen available before the partitioning part of our current installation is
reached. Currently we only knock back the partitioning with a warning after the
partitioner has been used. It needs full explanation before not a single line
after. It should be very easy to implement this text screen as the need far
outweighs the man hour time factor it would take to implement above.
I believe this should be assigned and completed as an urgent undertaking before
we ship another version as its benefit now and future is so very important.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=813340https://bugzilla.novell.com/show_bug.cgi?id=813340#c0
Summary: Suspected memory corruption in standard capi20 lib
Classification: openSUSE
Product: openSUSE Factory
Version: 13.1 Milestone 0
Platform: x86-64
OS/Version: openSUSE 12.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: jan.fengler(a)adviqo.com
QAContact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML,
like Gecko) Chrome/26.0.1410.43 Safari/537.31
The capi20 lib from the i4l-base source-package from
http://download.opensuse.org/repositories/home:/kkeil:/ISDN/openSUSE_Factor…
(and also Version 3.23-100.1 which is newer) seems to create memory corruption
during capi20_put_message sending data_b3_req, because no memory is assigned
for the data that is put behind the original message in the function
capi_processMessage (capi20.c row 962ff).
Unfortunately this seems to be a private function and so i could not easily
write a test against the entire lib.
Reproducible: Always
Steps to Reproduce:
I provide an example program that uses a 1:1 copy of the original function.
I use capi via JNI from Java and it crashes when freeing memory exactly as the
test program does.
Actual Results:
Memory corruption when freeing the memory used for the data_b3_req-message.
Expected Results:
No memory corruption, the program should terminate without a problem.
The last known working version (from openSuSE 10.3) assigned memory for
SND_BUFSIZ bytes and copied the original message to this before copying the
data bytes after the message and that worked.
I will change the code of the function standardPutMessage to do this to avoid
the problem and add a patch to this bug report if it works with the patch.
I must admit that i could have overseen something, but unfortunately it seems
not so far.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=872264https://bugzilla.novell.com/show_bug.cgi?id=872264#c0
Summary: 'hostname -s' returns "hostname: Name or service not
known" when content of /etc/HOSTNAME omits domain
Classification: openSUSE
Product: openSUSE Factory
Version: 13.2 Milestone 0
Platform: PC
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: mrmazda(a)earthlink.net
QAContact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
To reproduce:
1-configure /etc/HOSTNAME sans domain (no dots contained therein)
2-run any script containing 'hostname -s'
Actual behavior:
1-script output disrupted by return of "hostname: Name or service not known"
Expected behavior:
1-same output as if -s had been omitted from hostname call
Comments:
1-Cauldron and Rawhide both sensibly produce same short hostname output from
'hostname' as from 'hostname -s' when /etc/hostname omits dot(s)/domain.
2-According to the man page, 'hostname -s' should "Display the short host name.
This is the host name cut at the first dot.", as it does in current Cauldron
and Rawhide, whose hostname man page contains the identical description of -s
as Factory's.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=700065https://bugzilla.novell.com/show_bug.cgi?id=700065#c0
Summary: the wiki produces invalid XHTML
Classification: openSUSE
Product: openSUSE.org
Version: unspecified
Platform: x86-64
OS/Version: openSUSE 11.4
Status: NEW
Severity: Minor
Priority: P5 - None
Component: Wiki
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: giecrilj(a)stegny.2a.pl
QAContact: adrian(a)novell.com
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101
Firefox/4.0.1
The wiki pages are declared to be XHTML 1.0 Transitional. A script inserted
into every HEAD violates this declaration.
Reproducible: Always
Steps to Reproduce:
1. Validate <URL: http://en.opensuse.org/Main_Page >.
2. Inspect the document source.
Actual Results:
1. Line 21, Column 16: required attribute "type" not specified
2. <script>
Expected Results:
1. No errors
2. <script type="text/javascript" >
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=682920https://bugzilla.novell.com/show_bug.cgi?id=682920#c0
Summary: strange defaults in mailman
Classification: openSUSE
Product: openSUSE 11.3
Version: Final
Platform: Other
OS/Version: openSUSE 11.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
AssignedTo: jmatejek(a)novell.com
ReportedBy: suse-beta(a)cboltz.de
QAContact: qa(a)suse.de
Found By: Beta-Customer
Blocker: ---
(partly copied from
http://mail.python.org/pipermail/mailman-users/2007-November/058954.html
after seeing the same problem on 11.3)
I called "/usr/lib/mailman/bin/newlist mailman" to create the master mailing
list. Doing so resulted in the error
Bad owner email address: mailman@(unused)
The openSUSE Mailman package sets DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST to
'(unused)' in Defaults.py, which causes this problem.
Please use a default without parenthesis - according to the mail I linked
above, this should display the "correct" error message about an invalid list
address.
Of course it would be even better to have an error message that says
DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST need to be set - but that's probably
something for upstream.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.