Re: Make proposed available by default? [was: Setting NotAutomatic for hirsute+1-proposed]

[Seth Arnold]

On Thu, May 02, 2024 at 03:46:18PM +0100, Robie Basak wrote:
> Jammy:
> main 253K
> universe 75K
> Bionic (as an example of a mature release with fewer SRUs in flight):
> main 131K
> universe 9.7K

"omg the size" was my first reaction when I read the proposal, but these
sizes are far more reasonable than I expected.

But, I also expect very few of our users would use -proposed. What
percentage do you expect? I'm guessing less than 1%.

Instead of configuring proposed by default, I suggest that we should
make this work:

$ sudo add-apt-repository proposed
Unable to handle repository shortcut 'proposed'

https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1829588

The wiki instructions for using proposed is pretty rough. If it were just
one command I think it'd be a lot easier to encourage our users to provide
feedback on pre-production packages.

On Fri, May 03, 2024 at 06:23:05PM +1200, Michael Hudson-Doyle wrote:
> Maybe oracular is a good time to turn off some hashes and see what breaks.

Yes, please. Some people have to justify every use of md5 and sha-1 in
their environment. This is silly but it represents a real cost to some
of our users and no value to us.

I did a bit of quick experimenting with Noble:

$ gzip -cd */binary-amd64/Packages.gz > /tmp/Packages
$ grep -v MD5sum:  < /tmp/Packages | grep -v SHA1:  > /tmp/Packages-good-hashes
$ gzip -k9 /tmp/Packages-good-hashes
$ xz -k /tmp/Packages-good-hashes
$ gzip -k9 /tmp/Packages
$ xz -k /tmp/Packages
$ ls -l /tmp/Packages*
-rw-rw-r-- 1 sarnold sarnold 82509409 May  3 18:26 /tmp/Packages
-rw-rw-r-- 1 sarnold sarnold 76129409 May  3 18:31 /tmp/Packages-good-hashes
-rw-rw-r-- 1 sarnold sarnold 17909244 May  3 18:27 /tmp/Packages-good-hashes.gz
-rw-rw-r-- 1 sarnold sarnold 13842660 May  3 18:27 /tmp/Packages-good-hashes.xz
-rw-rw-r-- 1 sarnold sarnold 21542896 May  3 18:26 /tmp/Packages.gz
-rw-rw-r-- 1 sarnold sarnold 16844820 May  3 18:26 /tmp/Packages.xz

Maybe it's not fair to include -release since that is unlikely to change,
but this is rough and easy.

And since I can't help myself:

$ zstd -k -9 /tmp/Packages -o /tmp/Packages.zstd-9
$ zstd -k -16 /tmp/Packages -o /tmp/Packages.zstd-16
$ zstd -k -9 /tmp/Packages-good-hashes -o /tmp/Packages-good-hashes.zstd-9
$ zstd -k -16 /tmp/Packages-good-hashes -o /tmp/Packages-good-hashes.zstd-16
$ ls -l /tmp/Packages*zstd*
-rw-rw-r-- 1 sarnold sarnold 14408261 May  3 18:31 
/tmp/Packages-good-hashes.zstd-16
-rw-rw-r-- 1 sarnold sarnold 16304863 May  3 18:31 
/tmp/Packages-good-hashes.zstd-9
-rw-rw-r-- 1 sarnold sarnold 17456128 May  3 18:26 /tmp/Packages.zstd-16
-rw-rw-r-- 1 sarnold sarnold 19746359 May  3 18:26 /tmp/Packages.zstd-9

On Fri, May 03, 2024 at 08:43:11AM +0200, Heinrich Schuchardt wrote:
> On Debian I have seen apt-update downloading diff files. Why don't we use
> those for Ubuntu especially for the large files like Contents?

My experience with the 'pdiff' files was drastically increased apt update
time -- because the fixed costs of downloading files was a lot higher than
the throughput on larger files. Plus, these diffs also take up additional
space on the mirrors vs only storing the latest version. Maybe modern
http/2 or http/3 means it wouldn't be as bad as it used to be, but I'm
skeptical.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Changes in the container stack

[Seth Arnold]

On Tue, Aug 01, 2023 at 06:45:59PM -0300, Lucas Kanashiro wrote:
> With that in mind, we, the Server team, identified the need to decouple the
> application (what users really use) and the library (what is used by rdeps)
> in a way that, on the one hand, we can keep following upstream projects
> without worrying about breaking changes and on the other hand, we keep the
> library (-dev package) stable to avoid breakages of packages sync'ed from
> Debian or already in stable releases during SRUs.

Hello Lucas, I'm very concerned about this plan, I hope you can assuage my
fears.

This sounds like we'll introduce a new problem, where third-party
applications built against the libraries will become incompatible with
the main application.

If the ecosystems are changing external library ABIs too often, I can
only shudder in fear at how quickly internal library ABIs are changing.

What gives us the confidence that the internal ABIs are actually more
stable and reliable than the external ABIs?

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Reducing initramfs size and speed up the generation

[Seth Arnold]

On Mon, Jul 10, 2023 at 10:55:06AM +0200, Adrien Nader wrote:
> There is a little-know but very interesting property of LZMA: its
> decompression speed does not depend on the uncompressed size but only on
> the compressed size. What this means is that if you compress a 100MB
> down to 20MB, it will take roughly twice as long to decompress than if
> you compress it down to 10MB. In other words, higher compression means
> faster decompression.

This makes a certain amount of sense -- so much of a computer's
operational time is spent waiting for data to arrive from memory into
the processor, refilling cache lines, etc.

You nerd-sniped me into testing a bunch of algorithms on the
firefox_115.0+build2.orig.tar from our archive.

I only ran these things once, and quite a lot of them ran while a
second one was running, but this system (dual xeon E5-2630v3) has enough
processors and memory that it probably didn't matter much.

Times in seconds, with lower level on the left, higher on the right:

 1   3   5   9
compression:
gzip39  46  73 211
zstd 8  12  23  54
bzip2  228 237 249 265
lzma   154 294 643 945
xz 159 298 644 945

decompression:
gzip16  15  15  15
zstd 3   3   3   3
bzip2   68  73  74  75
lzma41  37  35  33
xz  36  32  31  30

xz of course absolutely dominates the end file sizes:

2989486080  original

 515273416  xz -9
 625958113  zstd -9
 647365812  xz -1
 666820870  zstd -5  (seemed like a sweet spot in the timings)

Anyway it's fun to see that gzip and zstd have consistent decompression
speeds, lzma and xz get faster as they go smaller, and bzip2 just gets
slower the more it has to think.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Reducing initramfs size and speed up the generation

[Seth Arnold]

On Sat, Jul 08, 2023 at 02:18:52AM +0200, Benjamin Drung wrote:
> Using xz -9 would give very good compression, but it takes very long
> (especially on slow development boards) and a lot of memory (good luck
> on Raspberry Pis with small memory like Pi Zeros).

Please also test decompression times for the various algorithms. I have
a special dislike for xz after seeing how long it takes even decent
machines to unpack Debian packages that were compressed with xz.

It's hard to know how exactly to balance compress and decompress times,
different users will have different ratios of booting vs installing
updates.

If it's possible to use zstd instead I bet it would provide faster
compression and decompression -- though at the cost of stressing those
tiny 512M /boot filesystems. (If we haven't switched to one or two
gigabytes by default, we ought to do that. I'm getting very tired of
teaching people how to recover from full /boot filesystems.)

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Symbols files for C++ libraries for Ubuntu main

[Seth Arnold]

On Thu, Jun 15, 2023 at 04:07:54PM +1000, Christopher James Halse Rogers wrote:
> abi-compliance-checker and abigail. None of those experiments have ended up
> sticking, though, for reasons which I'm not fully aware of. Alan Griffiths
> and Michał Sawicz did most of that investigation; I'll see if they can help
> shed light on problems we encountered.
> 
> If we *can* get (one of) the ABI checking tools working they'll be more
> valuable than a symbols file anyway, as they actually check that ABI didn't
> change rather than just that the symbol strings in the DSO match.

I'm not actually close enough to package updates to see how exactly these
different tools report symbols problems. I've tried reading the Debian
Wiki page, the KDE symbols page, etc, but without having these problems
myself, first-hand, it's hard for me to come to terms with the issues.

How do the default symbols files "failures" appear when building packages?
Are the results "actionable"? Or is the usual outcome to pave over the old
file and use a new file?

What's the ratio of false positives to true positives?

I keep hearing that the KDE symbols handling is vastly better; is there a
reason why it's not the default?

There's more to ABI compatibility than keeping the types of parameters and
return values lined up. Do any of the ABI tracking tools provide help
looking into the types, or the functions, etc?

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: How to ask for introducing a new package into main?

[Seth Arnold]

On Fri, Jan 20, 2023 at 08:44:21AM +, c.bu...@posteo.jp wrote:
> Am 19.01.2023 18:17 schrieb Gunnar Hjalmarsson:
> > Pls see https://github.com/canonical/ubuntu-mir
> 
> Nice process. It is not clear for me how do I open a bug report. The bug
> list on launchpad is closed. There is no "new bug report" item.

The bug would be opened on the source package of whatever package you're
trying to promote to main. If the package is in universe, that's pretty
easy, visit the package page for it:

https://launchpad.net/ubuntu/+source/PACKAGENAMEHERE

and click 'Report a bug'. Hopefully then the github piece will make more
sense.

If the package isn't actually in Ubuntu yet, it'll take more work. If you
get the package into Debian unstable, it'll automatically be imported into
Ubuntu universe by a syncing robot.

> I also think the process isn't worth and my request would be closed
> immediately. My arguments for the package is easy. It is still in Debian
> which is a quality fact by itself. So take it from there. Isn't Ubuntu
> itself "based on Debian"? What does this technically mean? You just copy
> some packages from a Debian repo?

There's nothing that says your request would be closed immediately, but
there's no denying that it would take more work. Promoting packages to
main requires a team bug subscriber: you'd want to talk to whichever team
would make most sense to maintain the package and discuss why it'd make
sense.

Why specifically main? What's wrong with universe?

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: pv (a pipeline progress indicator) in main?

[Seth Arnold]

On Wed, Apr 27, 2022 at 08:37:36AM +0200, Christian Ehrhardt wrote:
> The following would do, but since apparmor is an allow-list for mandatory 
> access
> that could end up reading weird unless there is a nice trick to
> allow-all-but ...
> 
> audit deny signal (receive, send) peer=/usr/bin/pv set=("exists"),

On Wed, Apr 27, 2022 at 08:40:34AM +0200, Christian Ehrhardt wrote:
> To some extent I consider this nothing more than an advanced version of
> DD having SIGUSR1 to report progress output - and that never was a problem.
> 
> I wonder, is everything with an IPC msgqeue a problem or is there something
> here that I do not yet see that makes this more affected?
> 
> Could you outline what level of concern you have here - see the starting
> quote of "just raising an eyebrow" and "total blocker" .
> 
> And if it is important - would trying to create any of the following
> help a lot to overcome your concerns?:
> a) something like the apparmor profile Thomas suggested?
> b) an opt-out option like "--no-remote - do not create IPC
> msgqueue for later change of arguments"
> c) it was just a hint and would not be a blocker

Thomas nerd-sniped me into looking at how it's implemented :) it's a
sysv message queue! which is very exciting, I don't think I've actually
seen one used in the wild before.

I didn't try to exploit it at all, but I had the impression that the worst
outcome would be fiddling with the interval, which is passed as a double.
Floating point values are very fiddly things and perhaps passing in a NaN
or trap representation or a crazy small or large value would lead to
unexpected behaviour.

An opt-out like --no-remote might be nice but it's honestly pretty hard to
see when anyone would choose to use that. An opt-in would be better if we
were designing this from scratch, but it's pretty well-known and widely
used now, so I consider that ship sailed.

Certianly this is no blocker, but another set of eyes for a few minutes
would be nice.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: pv (a pipeline progress indicator) in main?

[Seth Arnold]

On Fri, Apr 22, 2022 at 09:58:14AM -0700, Bryce Harrington wrote:
> LP page:  https://launchpad.net/ubuntu/+source/pv

> Or other considerations that need made before deciding?

pv is popular in the OpenZFS communities for use with zfs send | zfs recv
-- as is mbuffer, which exists more to provide much larger buffering than
the usual libc stdio buffers. mbuffer doesn't have progress bars, but does
show throughput:

$ dd if=/dev/urandom | mbuffer > /dev/null
in @ 32.5 MiB/s, out @ 32.5 MiB/s,  166 MiB total, buffer   0% full^C
341133+0 records in
341133+0 records out
174660096 bytes (175 MB, 167 MiB) copied, 5.13954 s, 34.0 MB/s
mbuffer: warning: error during output to : canceled
summary:  167 MiByte in  5.1sec - average of 32.4 MiB/s

One feature of pv that slightly worries me is that you can change the
parameters of an already-running instance by running it again, with -R:

   -R PID, --remote PID
  If PID is an instance of pv that is already running,
  -R PID will cause that instance to act as though it
  had been given this instance's command line instead.
  For example, if pv -L 123K is running with process ID
  9876, then running pv -R 9876 -L 321K will cause it to
  start using a rate limit of 321KiB instead of 123KiB.
  Note that some options cannot be changed while
  running, such as -c, -l, -f, -D, -E, and -S.

It's probably fine. (Afterall, it's possible to disable the yama sysctl
kernel.yama.ptrace_scope and attach a debugger to the process to modify
whatever you want.) But it's also possible it's not fine.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Restoring debhelper dh5 compat for the LTS?

[Seth Arnold]

On Wed, Mar 23, 2022 at 03:34:24PM +0100, Sebastien Bacher wrote:
> Those issues are easy to fix but I would prefer us to focus on spending our
> effort on more user impacting problems so I'm suggesting we revert the
> change for the LTS.
> 
> How do other feel like about that?

Thanks for raising this issue, Sebastien.

This change presents a problem for the security team's maintenance
activities: in order to fix future issues we would first need to upgrade
the packaging so it can build at all.

I made a survey of my local mirror and found 303 packages in jammy
have debian/compat files with "5" or "6". Not all will require security
support, of course, but it's hard to know what the ratio will be. (If
I've juggled my shell pipelines correctly, around 17 of these have had
around 65 CVEs.)

Can we please sync this change in May?

Thanks

$ awk -F/ '$2 ~ "srv" {printf "%-12s %-36s %s\n", $6, $8, $9;}' < 
/tmp/compat-5-6
main acpi-support acpi-support_0.143build1.dsc
main checksecurity
checksecurity_2.0.16+nmu1ubuntu1.dsc
main cdrkit   cdrkit_1.1.11-3.2build1.dsc
main gnu-standards
gnu-standards_2010.03.11-1.1.dsc
main libogg   libogg_1.3.5-0ubuntu1.dsc
main ltrace   ltrace_0.7.3-6.1ubuntu3.dsc
main mawk mawk_1.3.4.20200120-3.dsc
main pkcs11-helperpkcs11-helper_1.28-1.dsc
main raptor2  raptor2_2.0.15-0ubuntu3.dsc
main rasqal   rasqal_0.9.33-0.2.dsc
main redland  redland_1.0.17-1.1ubuntu2.dsc
main update-motd  update-motd_3.9.dsc
main wireless-regdb   
wireless-regdb_2021.08.28-0ubuntu1.dsc
main x-kitx-kit_0.5.0ubuntu4.dsc
main xbitmaps xbitmaps_1.1.1-2.1.dsc
main xfonts-scalable  xfonts-scalable_1.0.3-1.2.dsc
main xfonts-encodings 
xfonts-encodings_1.0.5-0ubuntu1.dsc
universe aa3d aa3d_1.0-8build1.dsc
universe add-apt-key  add-apt-key_1.0-0.5.dsc
universe alac-decoder 
alac-decoder_0.2.0-0ubuntu2.dsc
universe anagramarama anagramarama_0.3-0ubuntu6.dsc
universe apsfilterapsfilter_7.2.6-2.dsc
universe aspell-idaspell-id_1.2-0-0ubuntu1.dsc
universe asql asql_1.6-1.1.dsc
universe asterisk-prompt-fr-armelle   
asterisk-prompt-fr-armelle_20070613-2.1.dsc
universe asterisk-prompt-fr-proformatique 
asterisk-prompt-fr-proformatique_20070706-1.4-2.1.dsc
universe audio-convert
audio-convert_0.3.1.1-0ubuntu6.dsc
universe balloontip   
balloontip_2008.11.14-0ubuntu2.dsc
universe barada-pam   barada-pam_0.5-3.1build13.dsc
universe bf   bf_20041219ubuntu7.dsc
universe biabam   biabam_0.9.7-7.2.dsc
universe binutils-msp430  
binutils-msp430_2.22~msp20120406-5.1.dsc
universe bot-sentry   bot-sentry_1.3.0-0ubuntu1.dsc
universe bplaybplay_0.991-10build1.dsc
universe brother-lpr-drivers-mfc9420cn
brother-lpr-drivers-mfc9420cn_1.0.0-3-0ubuntu4.dsc
universe breathe-icon-theme   breathe-icon-theme_0.51.2.dsc
universe bve-train-br-class-323-3dcab 
bve-train-br-class-323-3dcab_20100711-0ubuntu2.dsc
universe byacc-j  byacc-j_1.15-1build3.dsc
universe bve-train-br-class-323   
bve-train-br-class-323_4.0.1809-0ubuntu3.dsc
universe cadaver  cadaver_0.23.3-2.1build1.dsc
universe cappuccino   cappuccino_0.5.1-9.1.dsc
universe cdi2iso  cdi2iso_0.1-0ubuntu3.dsc
universe choosewm choosewm_0.1.6-3build1.dsc
universe chrootuidchrootuid_1.3-6build1.dsc
universe cifercifer_1.2.0-0ubuntu5.dsc
universe chise-base   chise-base_0.3.0-2.1.dsc
universe cimg cimg_2.9.4+dfsg-3.dsc
universe clamassassin clamassassin_1.2.4-1.1.dsc
universe classmate-artworkclassmate-artwork_0.2-1.dsc
universe cli-common   cli-common_0.10.dsc
universe clif clif_0.93-9.1build2.dsc
univ

Re: Nominations: Developer Membership Board

[Seth Arnold]

On Thu, Mar 17, 2022 at 12:09:27PM -0700, Brian Murray wrote: > On Thu, Mar 17, 
2022 at 02:54:02PM -0400, Dan Streetman wrote:
> Haven't there problems with reaching the number of votes necessary for a
> quorum in the past? I'd rather see the team reduce in size[1] so that its
> easier for applications to be approved.

An alternative is changing quorum rules to eg "at least three voters"
and then even if N of the M team members are missing, it's much less
disruptive to the prospective new developers.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for nominations: Developer Membership Board

[Seth Arnold]

On Wed, Mar 09, 2022 at 02:43:40AM +, Seth Arnold wrote:
> I've been having this thought a lot the last few years.

My response here should in no way be read as suggesting Robie is
personally contributing to an excess of bureaucracy in Ubuntu. To the
contrary, I've always appreciated that Robie eagerly reaches out to
start conversations to reach a consensus.

This is strictly a lament that I don't think the structures we've got
are responsive to the needs of today. We've got a lot of roles to fill
and everyone in the project is stretched too thin to take on additional
responsibilities.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for nominations: Developer Membership Board

[Seth Arnold]

On Tue, Mar 08, 2022 at 10:37:07AM -0500, Dan Streetman wrote:
> In any case, all this formality really is exhausting and I don't care
> to pursue it, since you seem to be saying that I can't call for a DMB

I've been having this thought a lot the last few years.

A lot of the Ubuntu structures feel like they may have had a place in the
early days, when there were thousands of enthusiasts all contributing at
once and trying to coordinate how they were going to do all that.

Now it feels like we've got the ossified remains of a lot of committees
and teams and boards and I just don't know how much of it is still
relevant to the Ubuntu of today. Every piece serves a role so it's not
like I can just point to any one specific thing and say we ought to scrap
it, but I remember watching what felt like dozens of DMB meetings where
not enough members showed up, not enough members voted, and the poor
applicants could go weeks or months (or more?) without an answer.

That kills enthusiasm.

I'm sorry that I don't have a solution to recommend but I think I'd like
to suggest that we try stepping back from bureaucracy when opportunities
arise.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Revisiting default initramfs compression

[Seth Arnold]

On Wed, Dec 08, 2021 at 06:12:43PM +0100, Julian Andres Klode wrote:
> Question: Does zstd --adapt adapt to memory available?

"memory available" is very difficult to actually determine:
- is it physical memory on the machine?
- is it physical memory reported as "free" in /proc/meminfo?
- is it physical memory reported as "available" in /proc/meminfo?
- do you count memory used for buffers and caches as free?
- do you count memory available via swap as free?
- are there rlimits in place on the process that limit how much it can
  allocate?
- are there cgroup controls in place on the process that limit how much it
  can allocate?
- is this process the only meaningful process at the time? or are there
  other processes on the system that are more important?

I haven't actually looked to see if zstd tries to figure out how much
memory is free -- maybe it does, maybe it doesn't -- but I'd be worried
that relying upon it to do the right thing wouldn't work well for the
general case.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposal: sunset the backports pockets

[Seth Arnold]

On Mon, Jul 19, 2021 at 02:24:30PM +0200, Mattia Rizzolo wrote:
> I'd love to see it working the same way it works in Debian.  With
> random developers uploading (AND TAKING ON THEM THE RESPONSABILITY TO
> KEEP IT WORKING AND POSSIBLY UPDATED EVER AFTER), whilst a "team" is
> only tasked with basically verifying that the version string is sane and
> won't break update.

'Put the responsibility on the uploader' sounds like PPAs.

Ondřej Surý's PPA is a good example of a backports-like experience
where the developer has indicated how to report bugs in his package,
takes care to mark the packages with a visible version string to help
everyone properly triage issues, etc: https://deb.sury.org/

I think part of why -backports hasn't worked for Ubuntu in the time that
I've been paying attention is that PPAs do a decent job of replacing it.
Anyone who would be interested in using -backports can instead upload
to their own PPA and get immediate sucess.

I think it's time we remove -backports and all the documentation around
it. (Of course, actually removing packages from the -backports package
wouldn't be kind to the few using it, so we might not really be able to
clean up after it for a few years, but we can at least start the process.)

Yes even this requires doing work (and asking other people to do work).
But I can easily volunteer to clean up a few wiki pages, far easier than
I can volunteer to tend to the -backports pocket itself.

Thanks



ps I was curious to see how many packages are in -backports:

sarnold@wopr:/srv/mirror/ubuntu/dists $ for d in focal-backports 
bionic-backports xenial-backports trusty-backports; do echo === $d === ; pushd 
$d > /dev/null ; zcat */binary-amd64/Packages.gz | awk -F/ '/^Filename/ {print 
$4;}' | sort -u ; popd > /dev/null ; done
=== focal-backports ===
cockpit
ibus-typing-booster
lvm2
sanlock
=== bionic-backports ===
bird2
cockpit
debhelper
dh-autoreconf
elixir-lang
erlang
hvac
ibus-avro
ibus-typing-booster
init-system-helpers
iproute2
rabbitmq-server
smartmontools
vaultlocker
=== xenial-backports ===
ansible
appstream
autopkgtest
cockpit
debhelper
dh-autoreconf
distro-info
gir-to-d
golang-1.10
golang-1.10-race-detector-runtime
golang-1.9
golang-1.9-race-detector-runtime
ibus-avro
ibus-typing-booster
ldc
libarchive
lmdb
lxc
lxcfs
lxc-templates
lxd
meson
mustache-d
ninja-build
python3-lxc
=== trusty-backports ===
0ad
0ad-data
acsccid
ansible
apache2
asic0x
astyle
autopkgtest
boinc
cgmanager
cgroup-lite
chemps2
clamtk
clinfo
cppcheck
cppreference-doc
ddrescueview
dianara
drmips
duck
fio
flex
fonts-noto
gcalcli
gf-complete
git-dpm
gitolite3
golang
gramps
haproxy
hedgewars
icinga
identity4c
iperf3
iucode-tool
jerasure
jq
kdeconnect
keepalived
libcloud
liberasurecode
libndp
libnss-cache
libnss-securepass
libpam-ufpidentity
libqmi
libradsec
libseccomp
lmdb
lxc
lxcfs
lxd
makedumpfile
milou
minidlna
modem-manager-gui
moonshot-gss-eap
moonshot-ui
nagios-plugins-contrib
nautilus-admin
nautilus-hide
nvidia-modprobe
nvidia-settings
osm-gps-map
p4vasp
parsedatetime
pdns
php-apcu
povray
prodigal
prosody
pumpa
pyclamd
py-lmdb
pypolicyd-spf
pysimplesoap
pyspf
python-debianbts
python-geoip
python-ldap3
python-pkginfo
python-pyeclib
python-releases
python-socketio-client
qbittorrent
reportbug
screen
shellcheck
shibboleth-resolver
sosreport
spyder
squid-deb-proxy
stress-ng
svtplay-dl
swig
sysdig
tinyxml2
torsocks
transdecoder
twine
ubumirror
unity-tweak-tool
wesnoth-1.12
xfce4-whiskermenu-plugin
xml2rfc
yaggo
yelp-tools
yelp-xsl
zsh



signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Missing critical patches of several high-risk bugs

[Seth Arnold]

On Thu, May 13, 2021 at 10:22:05PM -0700, syzscope sys wrote:
> I just found out that Ubuntu is on the CVE CNA list.
> Do you think it's possible that Ubuntu could assign the CVEs for those
> issues directly instead of asking Google? Once the CVE is assigned, it
> should also not only benefit Ubuntu but also other potentially affected
> kernels.

Yes, Ubuntu is a CNA -- it's one of my roles. :)

I suggested using one of Google's CNAs for a few reasons:

- Google has vastly more resources than we do. Doing a decent job of
  assigning CVEs takes time and effort, and we're already trying to do
  too much with too few resources. Taking on the essentially unbounded
  amount of work of "assign CVEs for all syzkaller findings" is simply
  speaking not a commitment that I can make.

- Google's syzkaller and infrastructure is already doing the work to find
  and publicise the issues; it's quite common for vulnerability
  discoverers to use their own internal CNA resources for this.

I know Canonical, and Ubuntu users, would be better off if someone
assigned CVEs to these findings. It's just not something I can commit to
doing because of the scale of work involved.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maintenance report part 1

[Seth Arnold]

On Tue, May 18, 2021 at 04:35:56PM +1200, Michael Hudson-Doyle wrote:
> no_proxy but maybe we should do this always? I also don't understand how
> this works on other architectures -- if you do (python) s=socket.socket();
> s.bind(('0.0.0.0', 0)); print(s.getsockname()[0]) will you ever get an
> answer other than 0.0.0.0?

If this is the exact sequence, then I'm not sure. It seems unlikely.

However, if the actual sequence is a bit more involved, then yes, you can
get other results:

>>> import socket
>>> s=socket.socket()
>>> s.bind(('0.0.0.0', 0)); print(s.getsockname()[0])
0.0.0.0
>>> s.connect(('127.0.0.53', 53))
>>> print(s.getsockname()[0])
127.0.0.1
>>>

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Packaging policy discussion: After=network-online.target

[Seth Arnold]

On Thu, May 13, 2021 at 09:37:14AM -0300, Thadeu Lima de Souza Cascardo wrote:
> Maybe what needs to be provided here to avoid reimplementations is a better
> method to let services be more specific about what networks/addresses they 
> care
> about. That is, if we care about not having to reimplement this logic
> everywhere.

In the last week I've seen four different conversations about how to
properly start a service only 'after the network is up', and the different
people had different ideas of what this meant for their service:

- one wanted LAN up and working, nothing fancy
- one wanted to wait until DNS resolution was working
- one wanted to wait until an ospf daemon had negotiated routing
  tables and installed a default route
- one waited to wait until ntp had synced (not just started, but
  actually synced)

I think there's a real need for something better.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Missing critical patches of several high-risk bugs

[Seth Arnold]

On Fri, May 07, 2021 at 05:47:51PM -0700, SyzScope wrote:
> This is SyzScope, a research project that aims to reveal high-risk
> primitives from a low-risk bug.

Hello, this is pretty cool stuff. Continuing on 'executing' beyond the
point when ASAN has given up has given some pretty cool results.

I think the best way to get the most benefit out of this work is to
prioritize requesting CVEs for these issues with the Google CNA. Having
these additional details clearly visible to everybody using the CVE
infrastructure would benefit not only Ubuntu but also all our friends
in the other distributions.

There's two Google CNAs registered with the CVE project:
https://cve.mitre.org/cve/request_id.html
android-cna-t...@google.com
secur...@google.com

I'll be honest, I don't know which CNA would be better; you may need to
discuss the project with both in order to figure out how to best handle
the work.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maintenance report

[Seth Arnold]

On Fri, Feb 12, 2021 at 06:10:32PM -0800, Bryce Harrington wrote:
> This next set had test failures due to intermittent network issues, or
> other 'flaky' troubles, and passed on a simple retrigger.  (I'm not

Could we build a retriggerbot that smashes the retry button three times
before bothering any humans about failed tests?

Hitting retry is often the first troubleshooting step people take; I've
heard tests may be retried something like ten times by different people,
each of whom was taking a reasonable enough "first debugging step"
without noticing that other people have also done the same.

This way, any failures that bubble up to a human would be 'bad enough'
that it requires a human to address. (Of course, this may require tuning
the 'three' in my suggestion based on how many retries are usually
necessary.) Whoever is looking at an error could skip a retry at that
point and start right away looking at the test in question.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Adjusting what fstypes df displays

[Seth Arnold]

On Fri, May 29, 2020 at 05:14:13PM -0700, Bryce Harrington wrote:
> I haven't seen other examples of config file use elsewhere in coreutils,
> which was one reason I went with an env var for this POC.
> 
> I'll bring your points forward when I present to upstream, and if they
> also like the conf file approach better, I can reimplement it that way.
> Is there another GNU package (in C) that implements a systemd-style
> config file approach that you'd recommend to use for reference?

Yes, it could be that environment variables just "fit" better with the
rest of the GNU software.

I tried to find other examples and most GNU software either has
configuration customs that were established decades before this model
became popular, or this model wouldn't even begin to make sense.

All the same, I've found this model handy for keeping track of the
specific changes I care about to other software -- and I'm tired of trying
to teach how environment variables work -- so it seemed worthwhile to
suggest it anyway.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Adjusting what fstypes df displays

[Seth Arnold]

On Thu, May 28, 2020 at 09:38:47PM -0700, Bryce Harrington wrote:
> For Ubuntu, DF_EXCLUDE_FSTYPES could be set in the global profile (under
> /etc/profile.d/ perhaps?)  This would make it straightforward to add

Many thanks for working on this, df output has been annoying me for quite
some time (but I dislike shell aliases even more).

Properly threading an environment variable into a given process is
surprisingly difficult. /etc/profile.d/ is read by bash, and other
shells that choose to use these startup files. /etc/environment is
used by any PAM service that has pam_environment configured and
systemd-environment-d-generator(8) for systemd user manager instances.

These may not cover all instances where users would like it to. And,
ironically, even though it doesn't cover everything, it would be in the
memory of many processes that may never call df. It's not like it's a
huge amount of memory, but it is something.

Different tools like sudo, su, systemd-nspawn, lxc exec, etc may
further complicate getting an environment variable through from where a
human is interacting with the system to where df is executing.

So, I'd like to propose using the typical systemd-style configuration file
approach instead:

Package defaults in:
/lib/something/coreutils/df.conf or
/usr/lib/something/coreutils/df.conf

Sysadmin configuration in:
/etc/something/coreutils/df.conf

User configuration in:
XDG_SOMETHING_CONFIG/coreutils/df.conf
or
/run/uid/something/coreutils/df.conf

Yes, it's exhausting to implement the functionality for all this compared
to the simplicity of a getenv() or secure_getenv(), but filesystem access
is more predictable than environment variables from parents to children
and will likely work closer to expectations across chroot, schroot, lxd,
etc uses.

If we ever want to change the package defaults, then any local admin
choices already made could continue to be respected.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu HA resource-agents supportability

[Seth Arnold]

On Tue, Apr 07, 2020 at 03:54:11PM -0400, Dan Streetman wrote:
> > Xen - xen unprivileged domains
> 
> as cpaelzer mentioned, Xen should probably move up to the 'best
> effort' section; this was just moved out of main in focal.

Xen's status before focal was awkward: the source package and libxen were
in main because libvirt depended upon them. However, the hypervisor and
related utilities were in universe and not supported.

I'm not sure where exactly this Xen resource agent should be placed on
the list -- but in practice, Xen wasn't in main, and that may influence
your thinking.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: apport permission error

[Seth Arnold]

On Fri, Feb 14, 2020 at 09:31:55AM -0300, Thadeu Lima de Souza Cascardo wrote:
> > > > It's worth noting whoopsie-upload-all is run as root. I've discovered
> > > > that changing /proc/sys/fs/protected_regular from 1 to 0 allows
> > > > whoopsie-upload-all to write to the file. I imagine that apport is not
> > > > the only application affected by this setting.
> > > > 
> > > > What is the practical benefit of having protected_regular set to 1?

The Ubuntu Security Team would like to have these exploit mitigations
enabled if we can.

Application authors have been forgetting to add O_EXCL to their
open(O_CREAT) calls for decades; leaving it off is almost always a
mistake. protected_regular helps protect against a common exploit
mechanism.

However, among the systems I have easy access to, it appears
protected_regular wasn't enabled until focal[1].

I'm worried that turning this flag on for the first time in an LTS release
may be breaking too many expectations.

Adapting applications may be too much effort; because I don't know what
exactly apport is doing here it is hard to estimate how much effort it
will take to adapt it. Possibly the user-launched apport instances need
to create their own directory on launch. Possibly apport needs a
more invasive redesign.

> > Is there a system in place for tracking the number of breaks / programs
> > that have needed to adapt? As a follow on is there some way we could
> > search the archive for programs that will break because of this change?

Source code searching is not practical. The combination of working
with files in a world-writable sticky directory and not already using
O_EXCL with O_CREAT is not feasible to search for.

On failure, auditd will log entries that include "sticky_create_regular".
(I don't see any on my one focal system, but it is far from representative.)

> Any calls to fopen(..., "w") or fopen(..., "a") will use O_CREAT. But we are
> talking about opening a file for writing on /tmp/, where the usual pattern is
> using mktemp(3), then opening the file for writing. In this case, the file
> should not exist, and note that using mktemp is not advised, because of the
> races entailed. mkstemp is the recommended solution, where O_EXCL is also 
> used.

This is an excellent demonstration of the problem; often times
applications are using an abstraction layer that prevents easily adding
O_EXCL to the open(2) call.

> Now, once files are created there, they can be read from, moved, but not 
> opened
> for writing anymore, as lots of programs will end up using O_CREAT. Now, I
> can't answer if this is a pattern or not. You found one that is used for
> /var/crash/. Now, should /var/crash/ be world-writable? What does write there?

Debian Code Search suggests it's used without specific purpose:
https://codesearch.debian.net/search?q=%2Fvar%2Fcrash&perpkg=1

Apport, kernel crash dumps configured via the makedumpfile package, a tool
to clean up home directories, Intel openpath fabric tools, systemtap,
cockpit.

Interestingly enough, systemd-coredump(8) will write to
/var/lib/systemd/coredump instead of /var/crash.

> It has been like this since November. Though eoan would have been a better way
> to introduce it and see what breaks. As for the other options, at first, I
> would lean towards enabling them, but for regular files, it seems to be
> something that demands more thought.

Yes, eoan would have been the better time to enable this.

What will we use to determine when to enable this mitigation by default in
Ubuntu? We cannot expect all software to be adapted -- afterall, if all
software were adapted, then we would no longer need the mitigation. This
mitigation exists because a lot of software is potentially unsafe.

Addressing apport is probably part of the minimum. (I also wonder if we
could use systemd-coredump(8) to replace some of the more bug-prone
portions of apport.)

A Galera tool was recently fixed for protected_regular:
https://jira.mariadb.org/browse/MDEV-21140

Is there a third example of an application which trips over this
mitigation in a common usage?

Thanks again for bringing this up. We want this mitigation but if the
ecosystem is plainly not ready for it yet, we'd probably do more harm to
roll it out prematurely.

Thanks


[1]:
16.04 LTS:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1

18.04 LTS:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1

19.10:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:0
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:0
/proc/sys/fs/protected_symlinks:1

focal:
$ sudo grep -R . /proc/sys/fs/protected_*
/proc/sys/fs/protected_fifos:1
/proc/sys/fs/protected_hardlinks:1
/proc/sys/fs/protected_regular:1
/proc/sys/fs/pro

Re: Call for nominations: Developer Membership Board

[Seth Arnold]

On Fri, Feb 07, 2020 at 09:21:10AM +0100, Christian Ehrhardt wrote:
> P.S. Just an opinion and entirely up to you, the alternating meeting time
> is hard to plan for everyone.

I haven't kept close track of the meetings but my impression is that most
of them end with "well, there's no quorum, sorry you showed up, lets do
this next time or over email".

It's hard to have enthusiasm for this.

Can we replace the meeting with something else entirely, something that
fits better into the schedules of distributed, busy, people?

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Reconsidering Ubuntu bug-filing redirection

[Seth Arnold]

Thanks for raising this Colin, the redirection has been a source of
frustration among friends and users on IRC.

On Mon, Oct 14, 2019 at 12:13:30PM +0100, Colin Watson wrote:
> buried deep in a wall of text on
> https://help.ubuntu.com/community/ReportingBugs.  I find it very easy to
> see how people could read that multiple times and still miss it (indeed,
> over the years I've spoken to several people who have done exactly
> that).

It takes me a long time to find this every time I ask a friend to file a
bug for a problem they've found. Since I never see this myself, even finding
the right page takes a long time. (The very slow wiki server is an added
frustration.)

> == Suggestions ==

>  * Rearrange the UX for reporting bugs on Ubuntu as a non-member of
>~ubuntu-bugcontrol so that it presents the reference to ReportingBugs
>and the advice to use ubuntu-bug in a way that's hard to ignore but
>that can still be skipped.  For example, much like the way we
>currently have a first step of the bug-filing form that presents
>people with possible duplicates, we could have another step that
>guides people towards using ubuntu-bug; they'd only get the full form
>if they skip that as well.
> 
>(I'd suggest that a good test for whether this has been done well is
>if we can tolerate removing the special case for members of
>~ubuntu-bugcontrol.  It isn't a great sign when we have to exempt
>developers from something partly because it's too annoying.)

I like this. (Though I suspect the 'possible duplicates' behaviour
encourages users to comment on long-past bug reports. A new bug report
is almost always preferable to a comment on an ancient bug report.)

Anyway, having some way to sidestep the interruption while in the flow
of using the website would be very welcome.

>  * Remove the redirection entirely from /ubuntu/+source/PACKAGE/+filebug
>pages (though retaining the bug reporting guidelines displayed
>there), keeping it only on /ubuntu/+filebug.  This would still serve
>the purpose of stemming the flow of low-value bug reports that don't
>specify a package name, while making it easier for people who at
>least have some idea which bit of software is going wrong.

I don't have good visibility on how many low-quality bug reports we
get via the different interfaces, and no idea at all what the ratio of
"hypothetically good" vs "hypothetically bad" bug reports would be IF
people hadn't been deterred by the redirections.

I see low-quality bug reports filed against random source packages all
the time.

I rarely see bug reports of any sort against /ubuntu/ but they don't feel
significantly worse.

My suspicion is this would move some low-quality bug reports
to random source packages. "Just file all your bugs on
/ubuntu/+source/bash/+filebug" kind of cargo-culting.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Supporting LZ4 as initramfs compressor

[Seth Arnold]

On Thu, May 30, 2019 at 11:46:57AM +0100, Dimitri John Ledkov wrote:
> As if lz4 kernel & xz initrd would yield the fastest boot time? That

I'm lacking some context here, but I think building the initrds is already
too slow and I'm afraid xz on initrd rebuilds would be significantly
worse than lz4 or zstd or even low-compression levels of zlib.

Boot times are important but every now and then people do run apt upgrade
by hand and waiting forever to rebuild an initrd that may or may not be
used is pretty tedious. xz is great if the really slow compress times will
be made up for by better transfers or disk savings or similar.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: mlocate - what is it good for?

[Seth Arnold]

On Wed, May 22, 2019 at 09:47:22PM +0200, Julian Andres Klode wrote:
> I think mlocate only really makes sense on data storage servers with
> huge disks, or on machines with HDDs. I therefore do not think the
> overhead of building the index is warranted for most users. It might
> make sense to keep mlocate in always-on tasks, like servers, but get
> rid of it from desktop scenarios.

In my early days of using Linux, I used locate dozens of times a day. I
might know the filename but not the pathname, or a part of a filename,
etc.

"locate XF86Config" was way easier than "find / -name '*XF86Config*' -print".

Sure, the find command is simpler today, but it still spews loads of
useless error messages unless you also add 2> /dev/null. (And maybe
you care about some but not all errors. Unlikely but possible.)

Now that I'm far more familiar with where files live I no longer
use locate for this purpose. Now I fall firmly in the other camp,
where locate is annoyingly slow and I will try my hand at writing a
replacement someday:

$ time locate thisdoesntexist

real1m29.294s
user1m27.649s
sys 0m1.644s

Anyway, I believe locate can have great value to all our users,
experienced or brand new, huge systems or small systems. I'd like
us to keep it in default installs.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Maintaining language-specific module package stacks

[Seth Arnold]

On Wed, Apr 03, 2019 at 12:41:04PM +0100, Robie Basak wrote:
>  1. If a language-specific package, or stack of packages, is stuck in
> proposed, and nobody is volunteering to get them migrated, then we are
> more willing to delete them from the release pocket and release without
> that stack.

Thank you Robie for the proposal.

I believe this is in our users' best interests. I am conflicted, since I
know I much preferred getting the Ruby on Rails stack from Ubuntu when I
was using it many years ago, and continue to prefer using the Python and
Perl modules that we've packaged.

However, the status quo isn't doing anybody any favours. It might be
convenient for casual users but confuses the situation for everyone.

It's unfortunate that even if someone does step up to bring these
language-specific stacks up to the standard we expect for release,
it doesn't provide any assurances for users that these stacks will
be maintained. However, knowing that they are out of date at time of
release is worse enough that raising the bar even this little is useful.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

call for testing -- qemu / libvirt sandboxing on 18.04 LTS

[Seth Arnold]

Hello,

Jann Horn has discovered that qemu's seccomp blacklist is not properly
applied to all threads. This means the security hardening is nearly
useless.

We'd like to fix this issue so the users who opt-in to the seccomp
filtering will get the benefits they expect. However, this change feels
like it brings more than the usual amount of regression risk, so we'd like
to call for tests from the wider community.

If you're in a position to try an updated qemu package on 18.04 LTS,
we'd like to hear your results.

The bug report to coordinate the effort:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789551
The package repository:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3395

You may need to set seccomp_sandbox = 1 in your /etc/libvirt/qemu.conf
and restart the libvirt service and any running VMs.

Some errors may be difficult to spot. Some kernels will report seccomp
denials to dmesg or auditd and some kernels will not report anything.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: /usr-merge by default for new installations, with backwards compat

[Seth Arnold]

On Mon, Jul 23, 2018 at 01:41:03PM +0100, Dimitri John Ledkov wrote:
> In the Ubuntu Archive in cosmic all / vs /usr conflicts are resolved,

AppArmor profiles need to be adjusted:
https://gitlab.com/apparmor/apparmor/issues/8

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Inconsistencies in package versions for stable releases

[Seth Arnold]

On Tue, Jul 10, 2018 at 05:43:13PM +0100, Robie Basak wrote:
> pattern that so many developers seem to use. This is one that I want to
> resolve in the long term by encouraging via a lint tool first before
> turning it into a recommendation and eventually policy.

The Ubuntu security team has a shell-script function that helps us keep
the version strings consistent that may serve as a blueprint for such a
lint:

https://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/package-tools/check-source-package#L623

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: mass SRUing for changing triggers to noawait in progress

[Seth Arnold]

On Tue, Jul 10, 2018 at 10:35:21PM +0200, Julian Andres Klode wrote:
> Our goal is to get those changes into xenial before 18.04.1 so that 
> there are less upgrade failures. (Upgrade failures because the "await"

Oh nice, would this address bugs such as:

https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1745785
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1541716
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1573322
etc?

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [j...@debian.org: Frontend locking in APT clients]

[Seth Arnold]

On Mon, Jun 18, 2018 at 08:33:17PM +0200, Julian Andres Klode wrote:
> automatically sets DPKG_FRONTEND_LOCKED when invoking dpkg
> if the system lock is acquired (after the fork, directly
> before the execvp). If you run dpkg yourself, like for calling
> dpkg --configure -a you will probably have to set the environment
> variable yourself.

Hi Julian, I think I'm mostly excited about the lock changes you've
described (to the extent I recall previous discussions with you, this
has the potential to reduce some seriously confusing situations).

But dpkg --configure -a is already deep into the "unhappy user" territory
and needing to remember an additional environment variable to make it
work correctly is going to add an additional level of frustration.

Is there no way to make dpkg --configure -a work correctly without
manually setting environment variables?

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Symbols files for C++ libraries for Ubuntu main

[Seth Arnold]

On Fri, May 18, 2018 at 04:32:29PM +0100, Ian Bruntlett wrote:
> Having access to the source code for packages would be helpful because
> sometimes, when chasing down a bug, access to source code is desirable.

If you add "deb-src" lines to your apt sources, you can download the
source for a package to your current working directory with:

apt-get source source-package-name

for example..

sarnold@hunt:/tmp$ grep 'deb-src.*bionic' /etc/apt/sources.list
deb-src http://wopr/ubuntu/ bionic main restricted universe multiverse
deb-src http://wopr/ubuntu/ bionic-updates main restricted universe multiverse
deb-src http://wopr/ubuntu/ bionic-security main restricted universe multiverse
deb-src http://security.ubuntu.com/ubuntu bionic-security main restricted
deb-src http://security.ubuntu.com/ubuntu bionic-security universe
deb-src http://security.ubuntu.com/ubuntu bionic-security multiverse
sarnold@hunt:/tmp$ apt-get source bash
Reading package lists... Done
NOTICE: 'bash' packaging is maintained in the 'Bzr' version control system at:
http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debian
Please use:
bzr branch http://bazaar.launchpad.net/~doko/+junk/pkg-bash-debian
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 5,103 kB of source archives.
Get:1 http://wopr/ubuntu cosmic/main bash 4.4.18-2ubuntu2 (dsc) [2,428 B]
Get:2 http://wopr/ubuntu cosmic/main bash 4.4.18-2ubuntu2 (tar) [5,036 kB]
Get:3 http://wopr/ubuntu cosmic/main bash 4.4.18-2ubuntu2 (diff) [64.0 kB]
Fetched 5,103 kB in 0s (30.0 MB/s)
dpkg-source: info: extracting bash in bash-4.4.18
dpkg-source: info: unpacking bash_4.4.18.orig.tar.xz
dpkg-source: info: unpacking bash_4.4.18-2ubuntu2.debian.tar.xz
dpkg-source: info: applying bash44-019.diff
dpkg-source: info: applying bashbug-editor.diff
dpkg-source: info: applying deb-bash-config.diff
dpkg-source: info: applying deb-examples.diff
dpkg-source: info: applying man-arithmetic.diff
dpkg-source: info: applying man-fignore.diff
dpkg-source: info: applying man-bashrc.diff
dpkg-source: info: applying man-bashlogout.diff
dpkg-source: info: applying man-nocaseglob.diff
dpkg-source: info: applying man-test.diff
dpkg-source: info: applying man-test2.diff
dpkg-source: info: applying rbash-manpage.diff
dpkg-source: info: applying bash-default-editor.diff
dpkg-source: info: applying pgrp-pipe.diff
dpkg-source: info: applying input-err.diff
dpkg-source: info: applying exec-redirections-doc.diff
dpkg-source: info: applying bash-aliases-repeat.diff
dpkg-source: info: applying use-system-texi2html.diff
dpkg-source: info: applying bzero.diff
dpkg-source: info: applying man-macro-warnings.diff
dpkg-source: info: applying po-de-fix.diff
dpkg-source: info: applying man-vx-opts.diff
sarnold@hunt:/tmp$ cd bash-4.4.18/
sarnold@hunt:/tmp/bash-4.4.18$ ls
ABOUT-NLSbashline.cconftypes.hexterns.h  jobs.hparser.h 
   redir.h  trap.h
aclocal.m4   bashline.hcopy_cmd.c findcmd.c  lib   parse.y  
   shell.c  unwind_prot.c
alias.c  bashtypes.h   COPYINGfindcmd.h  list.cpatchlevel.h 
   shell.h  unwind_prot.h
alias.h  bracecomp.c   cross-buildflags.clocale.c  pathexp.c
   sig.cvariables.c
array.c  braces.c  CWRU   flags.hm4pathexp.h
   sig.hvariables.h
arrayfunc.c  builtins  debian general.c  mailcheck.c   
pathnames.h.in  siglist.cversion.c
arrayfunc.h  builtins.hdispose_cmd.c  general.h  mailcheck.h   pcomplete.c  
   siglist.hxmalloc.c
array.h  ChangeLog dispose_cmd.h  hashcmd.c  make_cmd.cpcomplete.h  
   stringlib.c  xmalloc.h
assoc.c  CHANGES   dochashcmd.h  make_cmd.hpcomplib.c   
   subst.c  Y2K
assoc.h  command.h error.chashlib.c  Makefile.in   po   
   subst.h  y.tab.c
AUTHORS  COMPATerror.hhashlib.h  MANIFEST  POSIX
   support  y.tab.h
bashansi.h   config-bot.h  eval.c includemksyntax.cprint_cmd.c  
   syntax.h
bashhist.c   config.h.in   examples   input.cNEWS  quit.h   
   test.c
bashhist.h   config-top.h  execute_cmd.c  input.hnojobs.c  RBASH
   test.h
bashintl.h   configure execute_cmd.h  INSTALLNOTES README   
   tests
bashjmp.hconfigure.ac  expr.c jobs.c parser-built  redir.c  
   trap.c

(Observant readers may have noticed the download came from cosmic rather
than bionic. Security team members have fairly unique apt sources to
support our tooling. Just ignore that detail. :)

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposal: Let's drop i386

[Seth Arnold]

On Thu, May 10, 2018 at 11:05:09PM -0700, Steve Langasek wrote:
> I do believe that the real question before us is that of dropping the
> architectures from the archive.
> 
> However, please note that as of 18.04, i386 and armhf are still supported
> architectures by Canonical for Ubuntu Core.  While there is as yet no

I believe deleting i386 and armhf before 18.10 is the politest thing to do:

- supporting these architectures in 2025 doesn't sound plausible
- thus supporting them in 20.04 LTS doesn't sound plausible
- thus we should not encourage our users to accidentally migrate off
  18.04 LTS to 18.10, 19.04, or 19.10.

*Maybe* if we modify do-release-ugprade to ask users to confirm typing
"I know what I'm doing" it wouldn't be so bad to support both arches
through 19.10.

But 20.04 LTS ought not include these architectures and I don't want to
strand anyone away from an LTS release.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Regarding linux-tools

[Seth Arnold]

On Mon, Mar 13, 2017 at 11:15:13AM -0500, Rohan Kadekodi wrote:
> When I tried to run the perf performance analysis tool (which is a part of
> the kernel) on kernel v4.9.x or v4.10.x, I realized that the linux-tools
> package of the respective kernel versions on which it depends are not yet
> included in the Ubuntu repository. Also, I could not find them online to
> compile them on my own.

Hello Rohan, can you please provide more details? At least the two most
recent 4.10.x kernels published to zesty appear to have the packages you
need:

https://launchpad.net/ubuntu/zesty/+package/linux-tools-4.10.0-13 (release)
https://launchpad.net/ubuntu/zesty/+package/linux-tools-4.10.0-14 (proposed)

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: To access IPP-over-USB printer: Emulate remote machine in the network

[Seth Arnold]

On Wed, Feb 22, 2017 at 04:42:46PM -0300, Till Kamppeter wrote:
> So it looks like that we need to work with an extra interface (dummy0 with
> IPv6) and find a way to let Avahi broadcast the interface's own host name or

Would you mind changing the name to something that would more clearly
reflect the reason why this dummy interface exists?

e.g., cups0 or cupsbrowser or cupslocal.

Ideally it'd be unique enough that searching the web for the name would
return our documentation about it and nothing else. 'dummy0' would easily
fail that test.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: netplan and post-up/pre-down scripts

[Seth Arnold]

On Tue, Jan 10, 2017 at 01:48:03AM -0800, Mike Pontillo wrote:
> Now, this may have a lot to do with the fact that I'm using the bridge; the
> behavior I'm describing may be very different for a "pure physical"
> interface. But with this setup, I see 5-minute timeouts at boot when I:

I'm sorry to say that I did not read this message with the attention it
deserves, but it's been a trying couple of days. So..

Is this a manifestation of the bridge trying to do spanning tree protocol?
Most of the walkthroughs I've read lately about bridged networking include
commands to turn off STP before they start adding ports to the bridge.

If you don't need it, try turning stp off:
brctl stp wan0 off
brctl stp lan0 off

(Is there a way to turn it off via iproute2 instead? I couldn't find it
quickly, if there is a way.)

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Rejecting SHA1-signed repositories by default (Ubuntu edition)

[Seth Arnold]

On Thu, Nov 24, 2016 at 01:19:12AM +0100, Julian Andres Klode wrote:
> as previously (sort of) announced I want to turn off SHA1 on January 1st
> by default in apt (in the 1.2 and 1.3 series xenial/yakkety ship). We
> already turned this off for fields inside the (meta) index files,
> this step now involves rejecting SHA1-based GPG signatures as well.

> The idea is that SHA1 gets rejected by default, but the
> error may be lowered to a warning instead. I do not intent

Hello Julian, thanks for working on this.

Currently retrieving 12.04 LTS package listings using 16.04 LTS's apt
packaging results in warnings like the following:

W: http://mirrors.kernel.org/ubuntu/dists/precise-updates/InRelease:
Signature by key 630239CC130E1A7FD81A27B140976EAF437D05B5 uses weak digest
algorithm (SHA1)

It'd be nice if the 'fail' could be configered per-release or per-deb
lines or something similar, so that I could still retrieve information
about older releases but newer releases get the enforced better security.

(Since 12.04 LTS EOLs in ~six months maybe this isn't worth addressing.
But I wanted to mention it all the same.)

May I also ask for the Valid-Until: lines to be turned on for zesty and
newer releases at the same time? I've heard various reasons why we don't
use it:

- An attacker could simply supply valid lists from before we started
  enforcing valid-until

- An attacker could simply block access to the update servers entirely.

I think these aren't in themselves good enough reasons to not use
Valid-until headers:

- If we had made this change back in, say, 10.04 LTS, we could have been
  publishing signed-and-dated files for six years by now. Today's
  users would be protected if we had done this then. Even if we have to
  grandfather these files in gradually, the sooner we start the sooner
  we will see benefit.

- A user may not think much of "I couldn't contact the update server
  today" whenever they happen to notice it. But if apt reports "the
  last valid update information is from N months ago" they may start to
  investigate why they do not get updates:

  - Perhaps their release is no longer supported
  - Perhaps some configuration mistake prevents it accidentally
  - Perhaps an attacker prevents it intentionally

Please consider making these changes at the same time.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: partman, recipes, sizing, swap, and all the things

[Seth Arnold]

On Wed, Nov 02, 2016 at 06:26:07PM +, Dimitri John Ledkov wrote:
> = Questions =
> 
> Is it sensible to change the semantics of the % specification in partman-auto?
> Or should e.g. a brand new factor be introduced?
> Is the introduction of pre-seedable swaplimit sensible?
> Is 2GB a good generic upper swaplimit?
> Is hardcoded 2 * 2.5% of disk space a sensible dynamic limit, or
> should that be preseedable as well?

This proposal feels a little complicated to me. We discussed swap at the
Athens sprint and I wrote down what I remembered from the discussion:

https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1566129/comments/3

In short:
- Use swap files
- Perhaps in a directory, so someone can just dd a new file alongside
  existing ones for additional swap space if locally required
- One gigabyte is very useful and not too painful

Obviously cloud guests with e.g. 10 gig roots can probably not afford
an entire gigabyte for swap, so scaling down in this case may still
be useful.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Promote adobe-flashplugin over flashplugin-installer

[Seth Arnold]

On Fri, Oct 28, 2016 at 05:37:48PM +0100, Robie Basak wrote:
> Are you saying that the additional download is a problem? If so, how
> exactly, and if not, then I don't follow how this mechanism makes a
> difference to users.

A wget or curl in a postinst command that fails (mediocre network
connectivity, unset http_proxy environment variables, temporarily failing
DNS, whatever) is going to be an unsightly mess to clean up if you're not
familiar with it.

The version of the package that downloads the flash binaries within the
package is going to be far more resilient against these failures, because
apt knows how to recover from nearly everything (except open wifi points
with captive http login portal nonsense).

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Seth Arnold]

On Tue, Jun 28, 2016 at 02:54:13PM +0100, Dimitri John Ledkov wrote:
> Let me resurrect this thread. In the context of what we should be
> doing in 18.04 and what to do between now and then.

Thanks for raising this again; it'd be nice to have a plan in place before
we wind up in a difficult situation.

> Here is an example draft plan to bikeshed over:
> 
> 16.10, 17.04, 17.10:
> * continue to provide i386 port to run legacy applications on amd64
> * continue to build i386 d-i / netboot installer
> * continue to build i386 kernel
> * continue to build i386 cloud-images
> * stop producing i386 ubuntu-desktop.iso
> * stop producing i386 ubuntu-server.iso

Note that at some point, we may need to stop supporting specific packages
on 32 bit systems. Some of our larger packages require modifications to
compile and link on 32 bit platforms and we're probably going to see one
or more of Firefox, Thunderbird, Chromium browser, Libreoffice, etc., no
longer buildable on small-memory platforms.

We may need to abandon upstream packages along the way. (And some of these
huge packages are not practical for us to backport security fixes.) (See
also, precise's chromium-browser.)

> 18.04 LTS:
> * continue to provide i386 port to run legacy applications on amd64
> * stop producing i386 d-i / netboot installer
> * stop producing i386 kernel
> * stop producing i386 cloud-images
> * stop producing i386 ubuntu-desktop.iso
> * stop producing i386 ubuntu-server.iso
> 
> 18.10+:
> * Stop providing i386 port
> * Run legacy i386 only application in snaps / containers / virtual machines

I'm afraid this proposal may strand some current i386 users on a release
with no lifetime to it.

16.04's 32 bit support has a five-year lifespan. We may not be able to
support the whole thing for the full five years but it should mostly work.

But if we release 16.10, 17.04, 17.10 i386, we're basically encouraging
users to install them and upgrade them and then find out in mid-2018 that
they've reached the end of their OS life and no way back to the safety of
16.04 LTS.

I propose that 16.04 LTS should be the last release with i386 support.
That way we don't leave anyone with a choice of (a) keep running
known-insecure 17.10 in 2018 or (b) figure out how to do a downgrade
back to 16.04 LTS.

I'm not sure how we acheive this specific goal but I think we shouldn't
encourage i386 (or armhf?) users off of 16.04 LTS.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ANN: DNS resolver changes in yakkety

[Seth Arnold]

On Tue, May 31, 2016 at 11:34:41AM +0200, Martin Pitt wrote:
> yesterday I landed [1] in Yakkety which changes how DNS resolution
> works -- i. e. how names like "www.ubuntu.com" get translated to an IP
> address like 1.2.3.4.

> Now DNS resolution goes via a new "libnss-resolve" NSS module which
> talks to resolved [2]. /etc/resolv.conf has the "real" nameservers,
> broken name servers are handled efficiently, and we have local DNS
> caching. NetworkManager now stops launching a dnsmasq instance.

Please forgive this email for rambling; it's length and lack of focus
may reflect questions and uncertaintyy the larger community may have,
however, so I'm sending it anyway. :)

== /etc/resolv.conf ==

/etc/resolv.conf appears to be both a resolved configuration file ("global
resolvers") as well as something it will publish for other programs to
consume (the symlink to /run/systemd/resolve/resolv.conf ).

- Which programs would consume data from this file? (My guess is 'native'
  lookup routines in languages like perl, python, ruby, erlang, java. Is
  this close? Who else would read from this file? Should we let them?)

- Would we want to stop using resolvconf? It feels like resolvconf's uses
  would be drastically less important with good systemd-networkd
  configuration instead. Would any cases remain where we want to keep
  resolvconf?

- Will we go with the symlink route (i.e., resolved is the publisher) or
  will we go with the regular file route (i.e., resolved is the consumer)?


== /etc/nsswitch.conf ==

> [2] This is configured in /etc/nsswitch.conf ("hosts: files ... resolve dns")

Do we even want to keep 'dns' on this line? If resolved fails to resolve
a request then falling back to DNS feels like it will simply push the
inevitable failure off by another six to eighteen seconds.

- When would 'hosts: .. resolve .. dns' be a better configuration than
  'hosts: .. resolve ..' ?


== replace dnsmasq's combined dhcpd and "local" dns ==

- Will dhcp leases handed out by systemd's dhcp server be automatically
  entered into the resolved database for lookups?

dnsmasq is used by many tools for these dual purposes and often times
chained together with resolveconf but the fact that it is _chained_
together means that e.g. containers can't look up VM names, or VMs
can't look up container names, when both VMs and containers are hosted
on one system.

I've spent enough time fighting dnsmasq and resolvconf that I'd quite
like to try replacing dnsmasq and resolvconf entirely. An NSS-based
interface may be able to do better.

Will we adapt lxd and libvirt and so on to use systemd-network so that
resolved and the systemd dhcp server stand a chance of replacing the other
tooling?


== LLDNS ==

Will we enable LLDNS? Do we want to? Responding too?


Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ANN: DNS resolver changes in yakkety

[Seth Arnold]

On Tue, May 31, 2016 at 10:45:24PM +0200, Martin Pitt wrote:
> resolved, which you can probably do in the order of a minute. It does
> not use source port randomization though, which would lift the average
> time to the magnitude of a month.

I'm concerned what this says about the maturity of the project: djbdns
introduced source port randomization back in 1999. PowerDNS has had source
port randomization for a decade now. Everybody else added this feature in
2008 when it got some Big Press:

https://dankaminsky.com/2008/07/24/details/
https://en.wikipedia.org/wiki/Dan_Kaminsky#Flaw_in_DNS
http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug
https://www.ietf.org/mail-archive/web/dnsop/current/pdf2jgx6rzxN4.pdf
https://www.iana.org/about/presentations/davies-viareggio-entropyvuln-081002.pdf
http://www.darkreading.com/vulnerabilities-and-threats/dan-kaminsky-reveals-dns-flaw-at-black-hat/d/d-id/1070756
https://kb.isc.org/article/AA-00924/0/CVE-2008-1447%3A-DNS-Cache-Poisoning-Issue-Kaminsky-bug.html

Source port randomization is a basic requirement these days.

Thanks


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC on Cloud Images: Make /tmp a tmpfs

[Seth Arnold]

On Wed, Jan 20, 2016 at 05:27:51AM +0100, Dustin Kirkland wrote:
> Sure, done!  You can find a detailed statistical analysis, as well as
> the raw data for your download and treatment at:
> 
> http://blog.dustinkirkland.com/2016/01/data-driven-analysis-tmp-on-tmpfs.html

This is great :) Suddenly the tmpfs for /tmp change makes sense to me.
As I see it, four out of 500-ish servers deserve /tmp on disk out of your
study. Maybe our machines are well-provisioned or well-run or both but
this feels like a fair conclusion to draw from the data available.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC on Cloud Images: Make /tmp a tmpfs

[Seth Arnold]

On Thu, Jan 14, 2016 at 12:27:58PM +0200, Dustin Kirkland wrote:
> Moreover, just 'sudo apt-get install swapspace' and watch as swapfiles
> are created/deleted as needed.  If your root disk is lvm-encrypted,
> then obviously such swap files are encrypted, too.

I've been severely skeptical of the swapspace package:

- Swap is used when the system is already under pressure; a few hundred
  megs is great and probably for the best but if the system is actively
  pushing beyond that then it's being pushed too hard.

- If the swap space is going to be allocated on the fly, that means the
  disk blocks have to zeroed on the fly, when the system is under
  pressure, rather than at some leisurely time beforehand.

- If the swap space is allocated on a filesystem, it's probably being
  allocated from a fragmented filesystem that's 90% full rather than a
  nice contiguous block of space as it would with a swap partition.

- Accessing further into a file may involve loading multiple indirect
  blocks from disk into unswappable kernel memory. A swap partition does
  not require indirection blocks.

- If the swap space allocated from a filesystem pushes the filesystem to
  95% full (or whatever is left after accounting for reserved blocks),
  programs will error and almost nothing handles "disk full" errors
  gracefully. Swap partitions do not cause surprise gigabyte losses in
  free space.

- Swap files can't be allocated from btrfs filesystems and probably
  shouldn't be allocated from zfs filesystems either. (Swap on zvols,
  maybe.)

Perhaps the swapspace package uses some tasteful tunables to mitigate
against my concerns but the end result is that it contributes extra load,
extra IO pressure, and extra uncertainty at a time when the system is
already experiencing too much load, too much IO pressure, and too much
uncertainty.

The risks and downsides of swapspace feel like a lot compared to the
slight hassle of having the installer make a swap partition.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC on Cloud Images: Make /tmp a tmpfs

[Seth Arnold]

On Wed, Jan 13, 2016 at 02:26:13PM +0200, Ben Howard wrote:
> On the Ubuntu Cloud Images, we have a request to make /tmp a tmpfs. The
> rationale, from the bug:

I'm afraid if you make this change you'll get requests to change it back:

- on m1.tiny and similar sized systems, /tmp will be so small that it may
  well be unusable for what applications expect to do
- using tmpfs for file storage will increase memory pressure and increase
  the likelihood of swapping, which is probably more painful.

Whether or not /tmp should be on tmpfs will vary from system to system. I
think the best we can do is make it easy to change between the two
choices.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC on Cloud Images: Make /tmp a tmpfs

[Seth Arnold]

On Wed, Jan 13, 2016 at 11:00:16PM +0100, Martin Pitt wrote:
> In a perfect world we'd have some clever tmpfs file system which would
> use RAM as available and start overflowing onto a disk partition
> (which could be LUKS with a random key) when necessary.. But even

In fact this is what happens, 'unused' data from tmpfs heads to swap. So
just configure swap space on your systems.

See https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt for
details.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Infiniband mstflint package SRU with new HW support provided by Mellanox

[Seth Arnold]

On Fri, Jan 08, 2016 at 01:56:38AM -0200, Rafael David Tinoco wrote:
> https://bugs.launchpad.net/ubuntu/+source/mstflint/+bug/1470167
> 
> There is a direct request from Mellanox for Ubuntu to sync "mstflint"
> package with Debian.
> 
> While that is okay for Xenial, after bisecting mstflint code with
> ConnectX-4 HBAs, I could see the exact commit that brings ConnectX-4
> HBAs support to mstflint is huge and does not fit into SRU guidelines.

A further comment in the bug reports that the mstflint in 14.04 LTS is
also too old to flash ConnectX-3 cards. While I might not expect trusty
to handle the ConnectX-4 cards out of the box I certainly would expect
ConnectX-3 to work.

I'd vote for the SRU of the newest package to the currently supported
releases where it makes sense. Our "new" SRU policy ought to make this an
easier task, and as mstflint is unlikely to have many depedencies, the
testing for it ought to be reasonable enough.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Backup api.

[Seth Arnold]

On Wed, Dec 16, 2015 at 05:22:27PM +0100, Stef Bon wrote:
> I will look for this application you've named but it will be hard as you
> describe. Snapshots/versions are available on a file level basis, not on a
> whole filesystem though.

If you're looking for filesystem snapshots you may wish to investigate
ZFS: their snapshot mechanism works on entire datasets instead of
individual files.

I understand Solaris modified the GNOME file manager to provide a slider
along the bottom that could be used to show previous snapshots of the
filesystem.

There'a s nice ZFS tutorial at:
https://pthree.org/2012/12/04/zfs-administration-part-i-vdevs/

More comprehensive ZFS documentation is at: http://zfsonlinux.org/

A quick overview of the GNOME time slider:
http://www.oracle.com/technetwork/articles/servers-storage-dev/autosnapshots-397145.html#introduction

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Xenial/grub2: Changes for Xen

[Seth Arnold]

On Mon, Nov 30, 2015 at 04:01:44PM +0100, Stefan Bader wrote:
> 20_linux_xen:
>  xen_list=`for i in /boot/xen*; do
> +if echo "$i" | grep -q '\.efi$'; then continue; fi
>  if grub_file_is_not_garbage "$i" && file_is_not_sym "$i" ; then echo 
> -n
> "$i " ; fi
>done`

Could this be changesd to use the same xen-*.gz you used in the
descriptive text?

   xen_list=`for i in /boot/xen-*.gz; do
   if grub_file_is_not_garbage "$i" && file_is_not_sym "$i" ; then echo 
-n
  "$i " ; fi
 done`

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proposal: enable stateless persistant network interface names

[Seth Arnold]

On Fri, May 08, 2015 at 07:27:39AM +0200, Martin Pitt wrote:
> Proposal
> 
> I propose to retire [mac], i. e. drop
> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> [ifnames] by default on all platforms (client, server, touch, snappy),
> and stop installing biosdevname on server.
> 
> This will provide the new stable interface names for all new
> installations, stop the different handling of server/client, work with
> system-image, and stops the woes cloud providers have with Ubuntu's
> [mac].

I know I'll complain about the new names endlessly, please allow me to
apologize in advance for that, but this makes sense to me. The original
eth0 style naming is quite fine for hobbiest machines where a human is
around to fix problems, but the number of situations it doesn't handle
gracefully is astonishing.

biosdevname seemed promising, except it seems to only partially work, and
I'm pretty sure I've seen more complaints about "renameX" interfaces with
biosdevname than without it.

So even though I'll never get the hang of the ifnames names, the fact that
they won't have race conditions that leave "renameX" noise around is alone
probably worth the transition.

How will ifnames handle:
- a new pcie interface is added?
- a pcie interface is moved to a different slot?
- two pcie interfaces are swapped?
- a quad-port pcie interface is replaced with a dual-port interface?
- usb interface added?
- a usb interface is moved to a different hub?
- two usb interfaces are swapped?

Will there be changes to myrinet or infiniband interface names too?

There will be endless amounts of documentation invalidated once 'eth0'
is no longer the name of the only NIC on the system; is there a handy
one-liner available to use to discover The Name Of The One NIC on
ifnames-based names?

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [RFC] CONFIG_ARM64_64K_PAGES=y for vivid?

[Seth Arnold]

On Mon, Dec 15, 2014 at 05:36:25PM -0700, Dann Frazier wrote:
> We've measured significant performance improvements for several
> benchmarks by using 64K pages (SPECint, sysbench mysql, and kernel
> compiling)[*]. I'd therefore like to discuss whether or not we should
> switch to 64K pages in vivid.
> 
> There's the question of whether or not we would be penalizing the
> performance of other classes of workloads people want to run on arm64.
> If there are some representative tests we should be looking at, please
> let me know.

There are arm64 cell phones; I suspect the workload on a cellphone is
different enough from a server workload that it should be tested as well.

The end results may indicate 64k pages are a win everywhere or they
may indicate a need for two arm64 flavours when we eventually target
higher-end phones.

Sorry, I can't recommend any benchmarks that would simulate the cellphone
workload.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ntp by default on servers in Vivid

[Seth Arnold]

On Mon, Dec 15, 2014 at 03:22:19PM +, Robie Basak wrote:
> If -g is specified to ntpd, then it will allow any variance the first
> time it sets the time. After that, and always if -g was not specified,
> it will exit (thus stop syncing time) if the variance is greater than
> 1000 seconds. I don't see any mechanism to configure this 1000s even
> though the manpage implies to me that it is configurable.
> 
> In Debian and Ubuntu, /etc/default/ntp sets the default parameter to
> "-g", so it looks like the time will always be fixed regardless of the
> variance when the daemon is first run.

Good, nice to know this quirk has been addressed.

> > It only makes sense to install ntpd if it will also be configured. Are we
> > going to use pool.ntp.org? This may work well enough for "simple" uses,
> > but does allow any member of pool.ntp.org to completely mess up times of
> > potentially hundreds of thousands or millions of users.
> 
> We're already using ntp.ubuntu.com when ntpdate is installed and ntp
> is not installed (the current default). When ntp is installed manually,
> this currently switches to pool.ntp.org.
> 
> If we make ntp default and do not seed ntpdate any more (my proposal),
> then this will change to using pool.ntp.org by default in all cases.
> 
> According to the default ntp.conf we ship, the decision to use
> pool.ntp.org was made by the TB, and I can see your concern was
> presented at the time (in LP bug 104525). It seems to me that a decision
> on this has already been made and would remain valid if we made NTP
> default. If you disagree though, please let me know soon and we can ask
> the TB for clarification.

After this was brought up, several members of pool.ntp.org contacted
me off-list and I got a very positive impression about the governance
of pool.ntp.org.

I still believe some companies would rather be in control of their own
time servers -- probably more should be in control of their own time than
I suspect actually are -- but by and large using pool.ntp.org should be
a vast improvement for most of our users compared against not using ntp.

> > Will it be easy enough for an organization to override the configuration
> > in each of the use cases you've described?
> 
> I'll need to address this question separately; thank you for asking it.
> You can always override /etc/ntp.conf, but perhaps this should be
> pre-seedable or something. There's also code to handle ntp-servers via
> DHCP; I should check to see what is active under which use case.

Pre-seedable and cloud-init would go a long way.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: ntp by default on servers in Vivid

[Seth Arnold]

On Wed, Oct 22, 2014 at 02:51:56PM +0100, Robie Basak wrote:
> I'd like to seed ntp in both server and cloud-image in Vivid. Servers
> should maintain the correct time by default. Please make any objections
> now.
> 
> Right now, ntpdate is seeded in minimal. It makes little sense to have
> both ntpdate and ntp installed.

Historically, ntpd would refuse to change the system time beyond a small
amount, so ntpdate was run in the initscripts for ntpd to make sure that
ntpd could keep things synchronized from then on. Is this still the case?
is this smallish amount of time configurable?

It only makes sense to install ntpd if it will also be configured. Are we
going to use pool.ntp.org? This may work well enough for "simple" uses,
but does allow any member of pool.ntp.org to completely mess up times of
potentially hundreds of thousands or millions of users.

Will it be easy enough for an organization to override the configuration
in each of the use cases you've described?

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Libav transition in trusty

[Seth Arnold]

On Wed, Jul 23, 2014 at 08:31:26AM -0400, Reinhard Tartler wrote:
> I wonder what's the current status on the Libav10 transition:
> 
> http://people.canonical.com/~ubuntu-archive/transitions/html/libav10.html
> 
> It appears to be stuck for some reason. Can we please push it through
> and manage the fallout afterwards?
> 
> Thanks for considering.

I understand that the libav transition is being held up in part by my
security review of librevenge:
https://bugs.launchpad.net/ubuntu/+source/librevenge/+bug/1328194

I expect to finish the review today or tomorrow.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: errors.ubuntu.com and upgrade crashes

[Seth Arnold]

On Fri, May 16, 2014 at 10:38:35AM +0100, Matthew Paul Thomas wrote:
> > At some point Firefox added a handy dialog box to alert running 
> > instances that it has been upgraded and should be restarted to run 
> > safely.

> Which Ubuntu then muddled by illustrating it with a small version of
> the Reload icon. 

I don't know if it is consolation or not but I never noticed anything
except the big "Restart" button in that dialog. :)

> > The person using Firefox simply clicks "restart" and six seconds 
> > later is back where he or she left off and the system runs
> > reliably again.

> Mozilla has the resources to include this function. Perhaps the
> LibreOffice team does too. But it's neither reasonable nor elegant to
> expect every app to do it.

This is something we could provide to the developers as a simple API.
onApplicationUpdate: high-level signal or a simple C function to install
the inotify listener that can signal the application's main event loop
when appropriate. We probably even already have a file in every package
that could serve as the inotify sentinal.

That way, applications that are brittle about having their resources
updated 'from underneath' can be prepared to do something about it.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: errors.ubuntu.com and upgrade crashes

[Seth Arnold]

On Tue, May 13, 2014 at 10:24:20AM +0100, Matthew Paul Thomas wrote:
> apps are expected to keep running during upgrades, then fix the
> upgrade process so that apps can't run during the upgrade. Don't just
> filter out those crashes as if they aren't happening.

For years, Mozilla and then Firefox would start showing the strangest
errors if it wasn't restarted during an upgrade. It was easy to forget or
otherwise not notice Firefox among the many updates being performed, and
wonder why four or five days later dialog boxes or menus weren't working
correctly. (Especially since the person performing the upgrade may be on a
different continent than the person running Firefox. Nothing says they're
the same person...)

At some point Firefox added a handy dialog box to alert running instances
that it has been upgraded and should be restarted to run safely. The
person using Firefox simply clicks "restart" and six seconds later is back
where he or she left off and the system runs reliably again.

Perhaps LibreOffice could adopt this mechanism; if it is not prepared to
be updated while running, it could be adjusted to inotify a sentinal file
to know to display a "please restart" dialog and button to avoid awkward
interactions and crashes.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Third Ubuntu Trusty test rebuild (all components, all architectures except powerpc)

[Seth Arnold]

Hi Doko,

On Fri, Mar 07, 2014 at 11:28:14PM +0100, Matthias Klose wrote:
> To prepare for the u-series, a second test rebuild using GCC 4.9 as the 
> default
> is run in parallel in
> https://launchpad.net/ubuntu/+archive/test-rebuild-20140307-4.9/
> The compiler used for this test rebuild can be found in the
> ubuntu-toolchain-r/test PPA.

I don't have permission to view these results; is this expected?

Does this new gcc-4.9 rebuild use any of the newer features such as
-fstack-protector-strong or is it a no-changes rebuild against 4.9 to
figure out what, if anything, might need to be modified for 4.9 support?

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: On-demand starting/stopping of cups [was: [Blueprint client-1305-printing-stack-with-mobile-in-mind] Printing Stack with Mobile in Mind]

[Seth Arnold]

On Tue, Feb 04, 2014 at 06:13:20PM +0100, Oliver Grawert wrote:
> i think it taking 30sec longer before it starts printing because the

Lets hope it isn't 30 actual seconds; I'm accustomed to hearing the
printer spool up near immediately. Thirty seconds is long enough that I'd
suspect something is broken and begin troubleshooting.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu 13.10 should be upgraded to LTS status

[Seth Arnold]

On Wed, Dec 18, 2013 at 11:33:08AM +0100, Oliver Grawert wrote:
> what scott said is absolutely right, XP users should just use 13.10 and
> upgrade to 14.04 once it is out.

Microsoft releases security updates on a monthly schedule; in the month
or so between XP's end-of-life and 14.04 LTS's start of life, things
are unlikely to change for the average XP user anyway -- it'll be a lot
like the preceeding month. :) Waiting a week or two for 14.04 LTS release
is likely also a suitable answer for XP users.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Server seeded package review

[Seth Arnold]

On Thu, Dec 05, 2013 at 05:15:41PM -0600, C de-Avillez wrote:
> Although I am probably hammering a rather cold iron, I still fail to
> understand why ntp is not installed by default. I would expect precise
> timekeeping to be something important on a server (instead of allowing
> the time to drift slowly).

I would like to hear from An Expert if ntpd, ntpdate, ptpd, etc., are
reasonable things to install in virtual machine guest environments.

My personal suspicion is that when a virtual machine host runs ntpd,
guests should not run ntpd, since two daemons attempting to skew the
clock sounds like a recipe for highly chaotic behavior. ntpdate would
be alright since it does not attempt to manage clock skew. ptpd no idea.

When the virtual machine host does not run ntpd, I suspect ntpd, ntpdate,
ptpd, are all fine things to run in the guests.

I'd love to know for certain what the best practices are. It might
influence the default package installs.

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Source packages appropriate by default?

[Seth Arnold]

On Tue, Jul 23, 2013 at 09:31:15PM -0400, Scott Kitterman wrote:
> /ubuntu/dists/raring-security/main/source
> 
> [ ]   Release 24-Jul-2013 01:16   106
> [ ]   Sources.bz2 24-Jul-2013 01:16   32K
> [ ]   Sources.gz  24-Jul-2013 01:16   38K
> 
> For end users, how much is really downloaded?

3 x 900 ms == 2.7 seconds

> /ubuntu/dists/raring-updates/main/source
> 
> [ ]   Release 24-Jul-2013 01:16   105
> [ ]   Sources.bz2 24-Jul-2013 01:16   50K
> [ ]   Sources.gz  24-Jul-2013 01:16   62K
> 

3 x 900 ms == 2.7 seconds

> /ubuntu/dists/raring-updates/universe/source
> 
> [ ]   Release 24-Jul-2013 01:16   109
> [ ]   Sources.bz2 24-Jul-2013 01:16   64K
> [ ]   Sources.gz  24-Jul-2013 01:16   77K
> 
> It doesn't seem like a lot.


3 x 900 ms == 2.7 seconds

2.7 x 3 == 8.1 seconds.

And yes, I've seen 900ms latency to our servers before, and I'm on a
reasonably quick connection, even by Korean or Swedish standards.

I'd hate to think what connectivity to our servers would be if I were
on a poor connection.

(I'm far happier now that I've switched to mirror.anl.gov; 70 ms latency
means my apt-get updates are now done in just 47 seconds rather than
the nearly two minutes I got when using our servers. But my needs are
a bit of an outlier..)

Perhaps HTTP/2's better use of single sessions[1] will improve things
drastically, but waiting for HTTP/2-compatible apt-get and servers feels
like a long way to go around turning off the deb-src lines by default.

[1]: http://www.chmod777self.com/2013/07/http2-status-update.html

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Xorg was removed.. without an alternative

[Seth Arnold]

On Wed, Jul 10, 2013 at 07:17:24PM -0400, Scott Kitterman wrote:
> > > The issue is that it's only in the *devel* pre-release when it's not safe
> > > for humans to enable it. The GUI for enabling it needs to exist because
> > > there are scenarios where humans should be enabling it: people using older
> > > stable releases who are crippled by some bug or other, and need to test
> > > SRUs sooner rather than later.
> > 
> > With this enabled, a "sudo apt-get dist-upgrade" will not pull from
> > -proposed, but
> > sudo apt-get install xorg/saucy-proposed , would allow me to
> > forcefully install xorg from saucy-proposed, as an opt-in - per
> > package choice.
> > 
> > [0] https://wiki.ubuntu.com/Testing/EnableProposed
> 
> What part of "not for humans" is confusing?

What will we do for SRU verification?

Will we introduce a new -proposed-for-humans pocket once Saucy
is released? Or will we need to go edit everything that once said
"saucy-proposed isn't for humans" to read "t-proposed isn't for humans"?

It seems so strange to spend six months saying "don't touch that" just
to turn around and then spend nine months begging people to touch that...


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Simple(r) sbuild setup

[Seth Arnold]

On Sat, Jun 22, 2013 at 03:21:33AM +0200, Michał Sawicz wrote:
> I've been happily using an sbuild setup (with apt-cacher-ng and building
> on shm - blazing fast!) based on [1] and [2], but the amount of
> information you're not generally interested in when you want to just try
> a build locally on that Wiki page made it so I couldn't really recommend
> going through it to anyone.

> [3] https://wiki.ubuntu.com/SimpleSbuild

This is excellent, thank you. I've wanted to recommend my building
configuration to other people before, but the amount of extra stuff on
the security BuildEnvironment page is pretty daunting. (Even setting up
a new computer is exhausting. :)

'umt' is a pretty awesome tool, but I can see how its use might be more
specifically awesome for the security team and less useful to everyone
else.

Thanks for condensing this down to something I'll be happy to hand out. :)



signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: non-Unity flavours and Mir

[Seth Arnold]

On Mon, Jun 17, 2013 at 09:00:29PM +0100, Jonathan Riddell wrote:
> On Fri, Jun 14, 2013 at 11:41:29AM -0400, Marc Deslauriers wrote:
> > Do you have any more details, or opened bugs about the issues?
> 
> An X one for example
> https://bugs.kde.org/show_bug.cgi?id=xrr-ubuntu

Hrm, I just skimmed it, but saw reports from openSUSE and Fedora users
in there as well. Are you sure that was the bug you intended to paste?

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: non-Unity flavours and Mir

[Seth Arnold]

On Fri, Jun 14, 2013 at 05:27:30PM +0100, Jonathan Riddell wrote:
> It's not a case of technical problems it's a case of Mir being
> different for no paticular advantage.  It's a political problem of

I for one am looking forward to finally having a fix for
http://bugs.launchpad.net/bugs/49579

Time will tell if fixing this bug is worth the other tradeoffs.



signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Call for testing: OpenSSL, compression security fix

[Seth Arnold]

Hi,

I have pushed updated OpenSSL packages for Ubuntu 10.04 LTS, 12.04 LTS,
12.10, 13.04, and Saucy into the -proposed pocket. Saucy's OpenSSL has
been accepted into -release.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed.

The packages fix the following security issues:

http://en.wikipedia.org/wiki/CRIME_(security_exploit)

The update disables compression before encryption for all applications,
unless the OPENSSL_DEFAULT_ZLIB environment variable is defined in the
program's environment at start.

Please report any issues in the tracking bug:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1187195

If no issues are reported, I plan on releasing the packages as security
updates in a couple of weeks.

Thanks,



signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Security implications of RT and memlock?

[Seth Arnold]

On Thu, Jan 17, 2013 at 02:35:58PM +0100, David Henningsson wrote:
> In a discussion with JACK developer Paul Davis, he says:
> 
> "at this point in time, i personally can see absolutely no reason
> why a regular user should not have access to RT scheduling or
> memlock if the kernel and PAM (or equivalent) are normally and
> appropriately configured. give the user the ability to memlock 75%
> of the system RAM, make sure that the RT scheduling parameters
> reserve 5% of the CPU for non-RT tasks. done."
> 
> The advantage of doing so is to remove one obstacle for having
> low-latency audio working OOTB, without manual configuration.

This feels like a surprising amount of resources to grant to a user. On a
single-user workstation, it would feel appropriate to allow the resources
to be used as desired, but it wouldn't be appropriate for multiuser
machines, shared-use systems, servers, etc.

But for the few that really want a top-to-bottom realtime audio
stack, adding a handful of /etc/security/limits.conf settings to
change RLIMIT_RTPRIO and RLIMIT_MEMLOCK (I'm surprised it doesn't
yet support RLIMIT_RTTIME, but without an explicit setting, probably
sched_rt_runtime_us applies equally to all users) does not seem so bad:
after all, those users also need to install and configure their software
and hardware.

64K might seem like a remarkably low per-process locked memory limit,
but it is per-process -- and on my 12.04 LTS laptop I'm allowed to
create 125874 processes; the locked memory works out to nearly eight
gigabytes in total, which feels like a lot. (Probably cgroups could
enforce some reasonable per-user limits rather than just per-process
limits.)

A realtime priority of 0 also doesn't seem too surprising; those
processes do win over non-realtime processes.

Is two lines in a configuration file really so unreasonable?

Thanks


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel