Re: tightvnc vulnerabilities
On Mon, 17 Dec 2018, Pavel Cheremushkin wrote: > Hello, > > I found this e-mail as a maintainer of xtightvncviewer package in Ubuntu > 18.04 release. > > I wanted to warn you that recently I have reported 4 vulnerabilities in > tightvnc 1.3.X, that is used in Ubuntu and developers refused to patch these > vulnerabilities. More information including overview of the vulnerabilities: > https://www.openwall.com/lists/oss-security/2018/12/10/5 > FYI, This is better handled via our bug tracker and I filed this bug on your behalf: https://bugs.launchpad.net/ubuntu/+source/tightvnc/+bug/1808989 -- Jamie Strandboge | http://www.canonical.com signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [14.04] nVidia GeForce 1080TI
On Thu, 2017-06-01 at 14:05 +0100, J Fernyhough wrote: > On 01/06/17 07:45, Sebastian Busse wrote: > > We are thinking of upgrading to current nVidia graphics cards. As far as > > I can see, the GeForce 1080 is supported since 367.27 while the GeForce > > 1080 TI is supported since 381.09. > > > > In Trusty Tahr, we seem to have access to 375 in the repositories. > > > > Do you plan on providing a version of the nVidia drivers >= 381.09 in > > the trusty repos? > > > > Trusty is EOL in about 10 months (April 2018); if you're upgrading > hardware you should probably be installing 16.04 on it. > April 2019, not 2018 (LTS is 5 years, not 4). -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Make systemd journal persistent | remove rsyslog (by default)
On Thu, 2017-01-12 at 10:50 -0500, Bryan Quigley wrote: > We could explicitly keep rsyslog supported in main for at least 18.04 > for the for those who need it (or indefinitely if we find it's still > needed for remote enterprise logging). I was thinking that we might > have to keep it in main until 18.04 anyway for upgrades. > I think this would be a hard requirement if it was decided on the switch. Another thing that came to mind is 'logcheck' (in main) for log auditing and I don't think it understands systemd-journald log format. logcheck is not installed by default of course, but it is another package useful in enterprise environments. If the standard logs are removed, then installing logcheck won't work by default and additional steps need to be performed to install rsyslog (and make sure systemd-journald forwards to it). There are two things here: 1. make systemd journal persistent 2. avoid duplicate logs from rsyslog Why not just do '1' and let rsyslog remain? The standard logs are rotated so this shouldn't be overly burdensome. Have you measured how much the duplicate logs would take on a typical system? > Kind regards, > Bryan > > > On Wed, Jan 11, 2017 at 5:32 PM, Jamie Strandboge wrote: > > > > On Wed, 2017-01-11 at 08:29 +0100, Martin Pitt wrote: > > > > > > Jamie Strandboge [2017-01-10 16:27 -0600]: > > > > > > > > > > > > Remote logging. Rsyslog is far superior in this regard. Granted, remote > > > > logging > > > > is not enabled by default but it is a requirement in many environments. > > > The systemd-journal-remote package does provide the necessary tools and is > > > reasonably flexible (push or pull, builtin https or using arbitrary ports > > > which > > > you e. g. could forward through ssh). It might not be as flexible as > > > rsyslog, > > > but as one needs to set up remote logging manually anyway, you always have > > > the > > > possibility of picking rsyslog, journal, or even something else. > > > > > Yes, but the 'logged to' system needs to be running systemd[1]. rsyslog > > speaks > > the standard syslog protocol on 514/udp, but systemd-journal does not. > > > > [1]https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.h > > tml > > > > -- > > Jamie Strandboge | http://www.canonical.com > > > > > > -- > > ubuntu-devel mailing list > > ubuntu-de...@lists.ubuntu.com > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo > > /ubuntu-devel > > -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Make systemd journal persistent | remove rsyslog (by default)
On Wed, 2017-01-11 at 08:29 +0100, Martin Pitt wrote: > Jamie Strandboge [2017-01-10 16:27 -0600]: > > > > Remote logging. Rsyslog is far superior in this regard. Granted, remote > > logging > > is not enabled by default but it is a requirement in many environments. > The systemd-journal-remote package does provide the necessary tools and is > reasonably flexible (push or pull, builtin https or using arbitrary ports > which > you e. g. could forward through ssh). It might not be as flexible as rsyslog, > but as one needs to set up remote logging manually anyway, you always have the > possibility of picking rsyslog, journal, or even something else. > Yes, but the 'logged to' system needs to be running systemd[1]. rsyslog speaks the standard syslog protocol on 514/udp, but systemd-journal does not. [1]https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Make systemd journal persistent | remove rsyslog (by default)
On Tue, 2017-01-10 at 17:04 -0500, Bryan Quigley wrote: > Hi, > > In debugging a shutdown issue I came across a bug [1] that indicates > for us to get better logs [2] during shutdown we really need to make > the systemd journal persistent. We would also need to remove rsyslog > by default so we don't have duplicate writing of logs to disk. > > Aside from shutdown logs we also get a lot of other nice metadata. > For instance, you can ask for all the logs since a certain date. You > can trivially view the logs from 2 boots ago. > > The negative is it is in a binary format and you have to use > journalctl to read it. > > I'm sure I missed some positives/negatives. Remote logging. Rsyslog is far superior in this regard. Granted, remote logging is not enabled by default but it is a requirement in many environments. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: How to file a bug against an unknown package? - Was: Green hard disk drives
On 08/14/2015 10:07 PM, Ralf Mardorf wrote: > On Sat, 15 Aug 2015 01:33:46 +0100, João M. S. Silva wrote: >> On 08/15/2015 01:12 AM, Ralf Mardorf wrote: >>> As already pointed out, the drive in question is _sdc_, not _sdb_ >> >> What about kworker? > > I wonder, if AppArmor or any of the other software I didn't chose to > install myself could be the culprit. > It isn't going to be apparmor-- there isn't a long running daemons. The security policy is loaded into the kernel on boot/package upgrade/etc then after that the kernel enforces it. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Owncloud 7 in Ubuntu >=14.10
On 01/07/2015 11:08 AM, Clint Byrum wrote: > Excerpts from Сергей's message of 2015-01-07 08:56:02 -0800: >> Hello. As I know, Owncloud wasn't added to Ubuntu 14.10 because of >> security problems. But since then new versions of Owncloud were >> released. Do they still have these problems? Are there any plans to >> add Owncloud to Utopic and/or Vivid? > > The problem with Owncloud is the same problem with Wordpress. They > operate at hyper speed and nobody wants to step up and maintain them > the same way Firefox/Chromium are maintained. > That said, the new Ubuntu Snappy[1] strives to make things easier for upstreams to reliably deliver software on their own schedule. [1]http://www.ubuntu.com/cloud/tools/snappy -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Critical Git Vulnerability
On 12/20/2014 06:45 PM, Alex Oh wrote: > http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html > > There is a vulnerability with git pull. Would be great if the git package can > be > updated to version 2.2.1. > > The current version is 1.9.1. > This issue is being tracked here: http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-9390.html -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Devuan
On 12/02/2014 04:24 AM, Martin Pitt wrote: > Stephen P. Villano [2014-12-02 5:11 -0500]: >> Personally, I prefer SElinux to polkit > > You know that these two have pretty much nothing in common, right? > Perhaps you meant "SELinux over AppArmor"? > > Indeed that's another example where Debian offers a choice but Ubuntu > doesn't -- we examine the alternatives, pick one, and support nothing > else. (cf. combinatorial explosion and efficient maintenance and > support). > Well, this is somewhat over stated for SELinux. AppArmor is the Canonical-supported MAC on Ubuntu, but SELinux is community supported in Ubuntu. The kernel has support and we have syncs for the tools from Debian. The policy needs work, but everything is there for people to use SELinux if they want to. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Package hamster-applet based off old source
On 05/24/2014 08:08 PM, Miguel Guedes wrote: > The package `hamster-applet' [0] is based off the (very) old 2.91.3 > release tagged in Nov 8 2010, though it seems to incorporate some more > recent code from (upto?) 2012 (git commit b9fec3e1). > > The project has since advanced considerably, in particular there have > been 7 releases since the old 2.91.3. > > Is there any reason why the package available in the Ubuntu repositories > has been kept back? Are there, perhaps, any incompatibilities/issues in > hamster's recent versions? > None that I am aware of OTOH. The package in Ubuntu is based off the package in Debian, which is 2.91.3+git20120514.b9fec3e1-1. I think Debian may be in the process of updating the package, so an update may be coming soon. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Application confinement, manifests and the Ubuntu SDK
On 07/05/2013 04:34 PM, Jamie Strandboge wrote: > On 07/02/2013 05:06 PM, Jamie Strandboge wrote: > >> ... >> >> In essence, packaging is updated to include a JSON manifest file and then >> updated to produce/install the apparmor policy and then load it into the >> kernel. >> The JSON security manifest will be a part of the larger click package >> manifest, >> but can also stand alone and be used with traditional packaging. Tools for >> using >> the security manifest with traditional Debian/Ubuntu packaging are in saucy >> now, >> with click package hooks coming online soon. >> >> I've created a wiki page[2] to describe the JSON structure, the meaning of >> the >> various parts, and how to use aa-easyprof in Click and traditional packaging. >> Some ideas on integrating this work: >> * generate a preliminary security manifest based on the type of application >>that is being created. If Ubuntu Simple/Tabbed Touch UI, use the >>ubuntu-sdk template with the qmlscene and qmlscene-sqlite policy groups. >> If >>a Ubuntu HTML5 Touch UI, use the ubuntu-sdk-html5 template with the >>qmlscene, qmlscene-webview and networking policy groups >> * prefill the manifest with entries based on the click packaging manifest[3] >> * follow the guidelines for using the manifest in traditional packaging[4] >> * in the short term, app developers could then modify the manifest from the >>SDK (nice JSON syntax highlighting and checking would be helpful), but >>eventually, provide some sort of a GUI that the app developer could use to >>pick and choose different policy groups. Right now, there aren't very many >>policy groups, but you can enumerate them with aa-easyprof and then expose >>them to the user as checkboxes. In the long run, it would be cool for the >>SDK to detect which policy groups are needed based on what the developer >>is doing with the code. >> * start fixing paths used by SDK applications to work within our application >>confinement strategy[5] (against ubuntu-qtcreator-plugins and tagged with >>'application-confinement') > > We've simplified this even more for click packaging[1] with a very reduced > security section of the manifest with many required sections handled > automatically. This should allow for the SDK to prefill the security section > of > the manifest with the basename of the desktop file as the profile name and set > the policy version (which could also be automated to use the highest version > on > the system). The click package apparmor hook will take care of the rest. > Policy > groups are now simplified such that the SDK could take the output of > 'aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-policy-groups' > and shove that list into GUI checkboxes for developers to choose from (ie, it > could be dynamic and the SDK wouldn't be required to have any knowledge of the > app or apparmor policy groups, but new policy groups would show up > automatically > without code changes). > > Traditional Debian/Ubuntu packaging will still need to prefill more fields > for now. > > [1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click > After more discussions surrounding click packaging hooks, desktop files and apparmor policy[1], the click manifest changed in a way that affects the SDK work and click packaging for core apps. Please see the security manifest documentation for details[2] for our part. Click documentation should be updated soon. (sorry, but this should be it and it will hopefully not be too difficult to change) Jamie [1]https://lists.launchpad.net/ubuntu-appstore-developers/msg00280.html [2]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Application confinement, manifests and the Ubuntu SDK
On 07/02/2013 05:06 PM, Jamie Strandboge wrote: > ... > > In essence, packaging is updated to include a JSON manifest file and then > updated to produce/install the apparmor policy and then load it into the > kernel. > The JSON security manifest will be a part of the larger click package > manifest, > but can also stand alone and be used with traditional packaging. Tools for > using > the security manifest with traditional Debian/Ubuntu packaging are in saucy > now, > with click package hooks coming online soon. > > I've created a wiki page[2] to describe the JSON structure, the meaning of the > various parts, and how to use aa-easyprof in Click and traditional packaging. > Some ideas on integrating this work: > * generate a preliminary security manifest based on the type of application >that is being created. If Ubuntu Simple/Tabbed Touch UI, use the >ubuntu-sdk template with the qmlscene and qmlscene-sqlite policy groups. If >a Ubuntu HTML5 Touch UI, use the ubuntu-sdk-html5 template with the >qmlscene, qmlscene-webview and networking policy groups > * prefill the manifest with entries based on the click packaging manifest[3] > * follow the guidelines for using the manifest in traditional packaging[4] > * in the short term, app developers could then modify the manifest from the >SDK (nice JSON syntax highlighting and checking would be helpful), but >eventually, provide some sort of a GUI that the app developer could use to >pick and choose different policy groups. Right now, there aren't very many >policy groups, but you can enumerate them with aa-easyprof and then expose >them to the user as checkboxes. In the long run, it would be cool for the >SDK to detect which policy groups are needed based on what the developer >is doing with the code. > * start fixing paths used by SDK applications to work within our application >confinement strategy[5] (against ubuntu-qtcreator-plugins and tagged with >'application-confinement') We've simplified this even more for click packaging[1] with a very reduced security section of the manifest with many required sections handled automatically. This should allow for the SDK to prefill the security section of the manifest with the basename of the desktop file as the profile name and set the policy version (which could also be automated to use the highest version on the system). The click package apparmor hook will take care of the rest. Policy groups are now simplified such that the SDK could take the output of 'aa-easyprof --policy-vendor=ubuntu --policy-version=1.0 --list-policy-groups' and shove that list into GUI checkboxes for developers to choose from (ie, it could be dynamic and the SDK wouldn't be required to have any knowledge of the app or apparmor policy groups, but new policy groups would show up automatically without code changes). Traditional Debian/Ubuntu packaging will still need to prefill more fields for now. [1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Application confinement, manifests and the Ubuntu SDK
Hi! In our application confinement specification[1] we define how to confine applications developed with the Ubuntu SDK using AppArmor (aa-easyprof). In short, the approach is to use template-based AppArmor policy (eg, ubuntu-sdk, ubuntu-html5, etc) along with AppArmor policy groups (eg, qmlscene, online-accounts, etc). The idea is that applications developer should not be required to know the ins and outs of Ubuntu and AppArmor, but instead they simply use the SDK and declare various accesses that the app needs. We know have all the low level bits in place such that the fine Ubuntu SDK folks can start integrating this work. In essence, packaging is updated to include a JSON manifest file and then updated to produce/install the apparmor policy and then load it into the kernel. The JSON security manifest will be a part of the larger click package manifest, but can also stand alone and be used with traditional packaging. Tools for using the security manifest with traditional Debian/Ubuntu packaging are in saucy now, with click package hooks coming online soon. I've created a wiki page[2] to describe the JSON structure, the meaning of the various parts, and how to use aa-easyprof in Click and traditional packaging. Some ideas on integrating this work: * generate a preliminary security manifest based on the type of application that is being created. If Ubuntu Simple/Tabbed Touch UI, use the ubuntu-sdk template with the qmlscene and qmlscene-sqlite policy groups. If a Ubuntu HTML5 Touch UI, use the ubuntu-sdk-html5 template with the qmlscene, qmlscene-webview and networking policy groups * prefill the manifest with entries based on the click packaging manifest[3] * follow the guidelines for using the manifest in traditional packaging[4] * in the short term, app developers could then modify the manifest from the SDK (nice JSON syntax highlighting and checking would be helpful), but eventually, provide some sort of a GUI that the app developer could use to pick and choose different policy groups. Right now, there aren't very many policy groups, but you can enumerate them with aa-easyprof and then expose them to the user as checkboxes. In the long run, it would be cool for the SDK to detect which policy groups are needed based on what the developer is doing with the code. * start fixing paths used by SDK applications to work within our application confinement strategy[5] (against ubuntu-qtcreator-plugins and tagged with 'application-confinement') The security team is available in #ubuntu-hardened, #ubuntu-touch, #ubuntu-devel, on this list and anywhere else you need us. Work is being tracked in the security-s-appisolation-sdk blueprint[6]. Thanks! [1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement [2]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest [3]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click [4]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Traditional_packaging [5]http://tinyurl.com/mf28tw4 [6]https://blueprints.launchpad.net/ubuntu/+spec/security-s-appisolation-sdk -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: No USN for Chromium on Ubuntu?
On 06/11/2013 10:00 AM, Robie Basak wrote: > On Mon, Jun 10, 2013 at 01:34:36PM -0500, Jordon Bedwell wrote: >> We just got DSA-2706-1 which upgraded Debian's Chromium to 27 but >> received no USN for the old version of Chromium in Ubuntu so I was >> wondering if there was going to be a USN and an update since normally >> I get USN's before DSA's. > > chromium-browser is in universe, and so is community maintained. Does > anyone want to volunteer to prepare, test and submit a suitable update? > If not, then I guess it won't happen. > Actually, Chad is already working on this (in CC). > Looks like a bug to track progress already exists: > > https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1183086 > > However, there was some talk about Chromium becoming the default[1][2]. If > this happens, then I presume that Chromium's main inclusion status > will change. > Updates will be provided but have been delayed due to armhf build failures. We recognize the delays are a problem and are (still) working on ways to improve this going forward. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Firestarter (Chris Jones)
On Mon, 2010-08-30 at 17:58 -0400, Scott Kitterman wrote: > On Monday, August 30, 2010 05:49:48 pm George Farris wrote: > > On Mon, 2010-08-30 at 14:20 -0700, Robert Holtzman wrote: > > > On Sat, Aug 28, 2010 at 09:22:40PM -0400, Greg Bair wrote: > > > > On 08/28/2010 08:35 PM, Robert Holtzman wrote: > > > > > I was under the impression that Firestarter was no longer being > > > > > maintained/developed. Wrong? > > > > > > > > Lastest stable, 1.0.3, was released in 2005, so I don't think so. > > > > > > See the section on Firestarter at > > > https://help.ubuntu.com/community/Firewall > > > > I just read this so maybe Firestarter won't be needed after all. > > > > http://www.omgubuntu.co.uk/2010/08/ubuntu-firewall-gui-for-ufw.html > > That's not particularly news. Gufw is available in all supported releases > except Hardy (and it can be gotten from hardy-backports there). Actually it is new, cause it isn't gui-ufw. ;) It is a new project called 'ufw-frontends', and I just found out about it myself. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Firestarter
On Sun, 2010-08-29 at 14:10 -0700, Jim Kielman wrote: > With the included tool for setting the firewall all you have to do is > enable the default rule set and it's done. The default rule set blocks > almost everything, and in Windows terms makes the users system seemed > to be stealthed. All you need is one simple command: > > sudo ufw enable > > And your done. If the defult rules aren't good enough, you can use gufw > for adding additional rules. > gufw is a fine graphical tool but I might also mention you can add rules with the ufw command-line-interface as well. Eg: $ sudo ufw allow OpenSSH $ sudo ufw enable See 'man ufw' for details. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Final Freeze approaching
On Mon, 2010-04-12 at 03:08 -0700, Steve Langasek wrote: > - For packages in universe that aren't seeded in any of the Ubuntu flavors, >this final freeze is nominal; packages must be manually accepted by the >archive admins, but no additional approval is required. This means that >if you *are* trying to get a package in that needs a FeatureFreeze >exception, it's important that you get release team approval *first*, >because the archive admins are not expected to check for an exception >approval before accepting these packages. What is the recommended way of determining if something isn't seeded in any Ubuntu flavors? I admit I've done little with seeds, so I went to SeedManagement then http://people.canonical.com/~ubuntu-archive/seeds/ and poked around, but there is a lot to check there. Should I be running germinate locally? Pointing me to an appropriate man page or wiki entry is enough. Thanks! -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: OpenSSL in Gutsy needs updating pronto
On Mon, 10 Mar 2008, George Orwell wrote: > All releases of 0.9.8 prior to 0.9.8f" > > Gutsy's current version is 0.9.8e, unless I'm incorrect isn't > this version vulnerable to this? > This was updated in October: http://www.ubuntu.com/usn/usn-534-1 Jamie Strandboge -- Email: [EMAIL PROTECTED] IRC: jdstrand signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
ufw firewall
ufw is a new firewall application that has recently been uploaded to universe. The goal is to have an easy to use firewall application for end users, while at the same time not get in the sysadmin's way. It is now in a state for wider testing. Important notes: * currently only host-based * cli * its disabled by default on installation * package integration is not (yet) implemented Please test and file bug reports in [1]. See [2], 'man ufw', and /usr/share/doc/ufw/README for more details. Jamie [1] https://bugs.launchpad.net/ubuntu/+source/ufw/ [2] https://wiki.ubuntu.com/UbuntuFirewall -- Email: [EMAIL PROTECTED] IRC: jdstrand signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Access denied (403) when trying to fetch security updates for Dapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Zimmerman wrote: > The security team should follow up to ubuntu-security-announce to notify > users who received the USN once they have prepared a response. > Updated packages are now available via security.ubuntu.com. The website has been updated with a new USN, and the new USN has been sent to [EMAIL PROTECTED] Details can be found here: https://www-admin.ubuntu.com/usn/usn-544-2 Jamie Strandboge - -- Email: [EMAIL PROTECTED] IRC: jdstrand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPwbBW0JvuRdL8BoRAszoAJ473g2kLKvdIu5jHaNbohNwLFex9wCfcdFU Lj2TYMyuYRFQlEeeLIvBx8U= =NVnG -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
