[TLS]Re: TLS trust expressions and certificate_authorities

[Dennis Jackson]

Hi Devon,

I'm a bit disappointed in how you've characterized the earlier 
discussion, but I appreciate the attempt to move the conversation on to 
new technical ground. I previously started a thread on the problems with 
the proposed uses of Trust Expressions for PQC-transition [1] in a 
similar effort to move the conversation on. It would be good to see a 
response from the TE authors to that thread.


Focusing on the actual draft text, the TLS trust expressions extension 
does not represent any kind of major paradigm shift, primarily due to 
its strong similarity to the existing certificate_authorities TLS 
extension.


[...]

There is no fundamental capability offered by trust expressions that 
isn’t already available by certificate_authorities.


I think the above captures the main thrust of your argument in this 
thread, but it seems like quite a flawed analysis. If T.E. does not 
offer any new capabilities over certificate_authorities, then there is 
no point in standardizing it at all. Conversely, arguments that T.E. is 
a much more effective mechanism for deploying trust negotiation than 
certificate_authorities undermines the claim that T.E. doesn't introduce 
new risks that merit discussion.


In terms of the differences between the existing certificate_authorities 
extension and Trust Expressions, I want to enumerate a few:


Firstly, certificate_authorities is impractical at any kind of scale 
because it requires listing the distinguished name of every CA in the 
ClientHello (as you noted). This makes the size blowup is a huge 
impediment to actually using it for anything other than in a private PKI 
setting e.g. for indicating which client_certs a server would like to see.


Secondly, certificate_authorities is very poorly supported today. TLS 
libraries typically ignore it e.g. OpenSSL requires custom callbacks to 
integrate it [2] - I couldn't find anything actually calling this 
function. Neither BoringSSL nor NSS support it in ClientHellos as far as 
can tell.


Thirdly, certificate_authorities doesn't have any of the machinery 
necessary to orchestrate deploying it. Trust Expressions envisions ACME 
/ TLS Servers implementations and CAs cooperating to distribute these 
trust labels to subscribers without requiring them to do any 
configuration themselves.


Trust Expressions proposes to solve all of these drawbacks with 
certificate_authorities. The first is achieved by replacing the long 
list of distinguished names with a single identifier. The second is to 
ship support across servers and clients and make sure it is well 
exercised and indeed required. The third is to ensure that CAs can 
deliver multiple certificate chains to clients and that clients can 
transparently select between them based on a trust label.


Consequently, T.E. does meaningfully change the calculus over 
certificate_authorities and so there are number of active threads 
discussing the risks of enabling trust negotiation and evaluating how it 
can be abused.


Best,
Dennis

[1] https://mailarchive.ietf.org/arch/msg/tls/b_S23Rk0yvleoT3D0BGUTYFut80/

[2] https://github.com/openssl/openssl/issues/13453

On 11/06/2024 02:24, Devon O'Brien wrote:


Hello,


I realize there has been extensive discussion about trust expressions 
and a variety of hypothetical scenarios that some believe will play 
out should this draft get adopted and implemented. I would like to 
start this out with a clear statement: we hear these criticisms and 
are paying very close attention to them in order to help ensure this 
working group does not ship an irresponsible standard that causes any 
of the possible doomsday scenarios sketched out. The crux of this 
disagreement isn’t whether the outlined hypotheticals are bad; we are 
in strong agreement on this point. Rather, the disagreement is about 
the causality being posited between a rather incremental extension 
mechanism and these outcomes. Here, we authors strongly disagree with 
the points that have been repeatedly mentioned by some working group 
members and I hope that a more careful analysis of what trust 
expressions actually provide over the status quo will help the working 
group work past these disagreements.



I believe that, in our excitement at the opportunities that a more 
agile web PKI can provide, we did ourselves and the broader community 
a disservice by leaning too far into some of the far-reaching 
possibilities we envision from a world with trust expressions. While 
we remain excited about a more agile and less-ossified PKI, it’s now 
clear that such emphasis caused the conversation to shift dramatically 
away from what the draft actually says and towards a variety of 
opinion-based arguments about what laws may be written by various 
world governments in the coming years and decades.



Focusing on the actual draft text, the TLS trust expressions extension 
does not represent any kind of major paradigm shift, primarily due to 
its strong similarity to the existing

RE: Today's WWDC keynote and iOS 18 announcement

[Dennis Long]

I agree.
 
From: viphone@googlegroups.com  On Behalf Of Sieghard 
Weitzel
Sent: Monday, June 10, 2024 5:45 PM
To: viphone@googlegroups.com
Subject: RE: Today's WWDC keynote and iOS 18 announcement
 
We all know what Siri is like right now, but with full AI integration I have a 
feeling we may all be surprised how amazing it may end up being; of course from 
the little I heard this will not be one of these on/off moments where as soon 
as iOs 18 is released in September it will include all of what it will have a 
year from now and after the main .1, .2 and .3 updates which typically happen 
in Late October, before Christmas or in the new year and again in early March. 
And then of course it is my understanding that the true Apple Intelligence will 
require at least an iPhone 15 Pro or later so for many of us it may be years 
before we experience it all and by then of course even more powerful hardware 
and advances in AI will even add more functionality. One thing I am sure of is 
that in the next years we'll see a lot of cool stuff around all the AI 
development and we'll benefit greatly from it.
 
From: viphone@googlegroups.com   
mailto:viphone@googlegroups.com> > On Behalf Of 
Cristóbal Muñoz
Sent: Monday, June 10, 2024 12:30 PM
To: viphone@googlegroups.com  
Subject: RE: Today's WWDC keynote and iOS 18 announcement
 
I literally asked Siri this morning what time was the WWDC keynote and I got 
one of those generic “”this is what I found on the web.”
Whatever they do or don’t’ do with Siri, it can’t be as bad as it is X years 
later than when it was introduced. Just one hot useless mess.
 
Cristóbal
 
From: viphone@googlegroups.com   
mailto:viphone@googlegroups.com> > On Behalf Of Tai 
Tomasi
Sent: Monday, June 10, 2024 11:10 AM
To: viphone@googlegroups.com  
Subject: Re: Today's WWDC keynote and iOS 18 announcement
 
We are currently into a whole new section where they talk about AI. They just 
separated it.
Tai Tomasi, J.D., M.P.A.
Email: tai.toma...@gmail.com  
Sent from my iPhone. Please excuse my brevity and any grammatical errors.
 
On Jun 10, 2024, at 2:08 PM, Sieghard Weitzel mailto:siegh...@live.ca> > wrote:
 
After all the hipe in the tech media about how Apple was going to announce how 
Siri in iOS 18 would be deeply integrated with AI, it was disappointing to 
listen to the section about iOS 18 and to my knowledge not hear the word Siri 
or AI even once. Of course this could still mean that Apple decided to not go 
into this because maybe it's not yet ready to be presented and we'll hear all 
about it when the new iPhones are released in September, but I thought it was a 
bit of a let down anyways.
 
Best regards,
Sieghard
 
-- 
The following information is important for all members of the V iPhone list.
 
If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.
 
Your V iPhone list moderator is Mark Taylor. Mark can be reached at: 
mk...@ucla.edu  . Your list owner is Cara Quinn - you 
can reach Cara at caraqu...@caraquinn.com  
 
The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/PH7PR12MB5656886BFAF73A7000DAB3E8C7C62%40PH7PR12MB5656.namprd12.prod.outlook.com
 

 .
-- 
The following information is important for all members of the V iPhone list.
 
If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.
 
Your V iPhone list moderator is Mark Taylor. Mark can be reached at: 
mk...@ucla.edu  . Your list owner is Cara Quinn - you 
can reach Cara at caraqu...@caraquinn.com  
 
The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com 
 .
To view this discussion on the 

Re: [PATCH 3/3] ui/cocoa: Adds support for mouse cursors

[Phil Dennis-Jordan]

On Sun, 9 Jun 2024 at 11:06, Akihiko Odaki  wrote:

> Thanks for working on ui/cocoa, but I already have submitted a patch for
> this particular problem:
> https://patchew.org/QEMU/20240318-cursor-v1-0-0bbe6c382...@daynix.com/
>

Sorry, I missed this patch set - thanks for bringing it to my attention.


> The difference between these patches is that my patch does not use
> warping at all. I thought reversing the mouse movement bias is a fragile
> approach that depends on the details of how Quartz works.
>

Hmm. So, I agree that the relative cursor implementation with NSCursor is
somewhat awkward. I'm not sure it's as fragile as you make out as the
behaviour of the APIs used hasn't changed in decades and has plenty of
existing software depending on it. Still, it might behave awkwardly in the
context of other apps warping the cursor at the same time. I also
definitely think host cursor integration is useful and valuable, at least
in absolute pointing mode - for example, when the host system is itself
being remote controlled, and also to avoid the cursor being cropped near
the edges of the guest viewport.

The CALayer based rendering makes sense to me in relative mode though. For
one, it avoids the complicated event offsets. The cursor cropping actually
makes sense as a visual cue when the cursor is actually constrained to the
guest viewport while mouse input is grabbed. And because the guest cursor
is decoupled from the host cursor even after ungrabbing, it makes sense to
continue rendering it even when Qemu has relinquished the host cursor.

I've therefore reworked my NSCursor code on top of your CALayer cursor and
change notifier work so that the NSCursor is visible and updated with the
guest's cursor image when in absolute mode, and the CALayer draws the
cursor in relative mode. Because of the chain of patch dependencies I've
staged it on gitlab here for initial feedback/testing/review:
https://gitlab.com/pmdj/qemu-upstreaming/-/compare/master...m-cocoa-cursors-2.0?from_project_id=53960510=false

Let me know what you think. If we decide to go with this approach we can
post our respective patches as a combined v2 patchset to the list.

Incidentally, that version of my NSCursor patch includes a few
refinements/fixes to the CALayer patch which I'll tease out into a separate
commit, and which I'd recommend applying even if consensus settles on a
CALayer-only approach. (setCursor: was rather long and messy; it also
leaked a colour space object; layer and cursor objects would leak if the
view was hypothetically dealloc'd)

Thanks,
Phil

[marxmail] Hamas and the Left - apologies if already posted

[Dennis Brasky]

Excerpts - Ultimately, the Western left’s quixotic search for a secular
progressive alternative to Hamas overlooks a simple fact: at this
particular historical juncture, the political forces that are still holding
onto and leading a resistance agenda are not of the secular left.



Hamas is an easy scarecrow here. It is an Islamist political group that
both centers a politics of defiance and pushes a social agenda that seeks
to reconstitute the Palestinian subject. Critics of resistance can easily
point to shortcomings in Hamas’s socioeconomic outlook or deride its
“socially regressive” agenda. But they aren’t really interested in
undermining Hamas’s social agenda. In truth, they want to undermine or
distance themselves from the form of resistance that Hamas chose to pursue.
But many of Hamas’s critics offer nothing in their alliance system, in
their forms of struggle, or even in their intellectual output that could
match its work to accumulate power in the Gaza Strip and its opening of a
strategic pandora’s box that has overflowed and deformed the colonial
regime, providing a historical moment that includes among its many
possibilities the potential for Palestinian liberation.



Hamas isn’t going anywhere in Palestinian politics. It is an energetic
political entity that has astutely learned from the mistakes of its
predecessor, the PLO, both in warfare and negotiations. It has meticulously
invested its intellectual, political, and military resources into
understanding Israel and its psychic center of gravity. Whether we like it
or not, Hamas is now the primary force leading the Palestinian struggle.



The left must confront this basic fact. One cannot ground solidarity with
Palestine on a politics that dismisses, overlooks, or excludes Hamas. This
stance fails to grasp the complexities and contradictions inherent in the
Palestinian struggle. In doing so, the left overlooks the dividing line
between collaboration and resistance to its peril.



The Left must confront this basic fact. One cannot claim solidarity with
Palestine and dismiss, overlook, or exclude Hamas.
Full - https://mondoweiss.net/2024/05/the-question-of-hamas-and-the-left/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30712): https://groups.io/g/marxmail/message/30712
Mute This Topic: https://groups.io/mt/106591523/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

SORBS closing

[Dennis Eriksen]

Hi,

It seems that SORBS [1] has shut down [2][3][4], so heads up to anyone
using SORBS as a dnsbl.

I believe SORBS at least *used* to be the default list in filter-dnsbl.

1: <http://www.sorbs.net/>
2: <https://www.mail-archive.com/postfix-users@postfix.org/msg102408.html> 
3: <https://www.theregister.com/2024/06/07/sorbs_closed/>

4: <https://www.linkedin.com/feed/update/urn:li:activity:7202108788026335233/>

--
Dennis Eriksen

Re: [PATCH 2/3] hw: Moves int_clamp() implementations to header

[Phil Dennis-Jordan]

On Sun, 9 Jun 2024 at 11:00, Akihiko Odaki  wrote:
>
> On 2024/06/09 5:20, Phil Dennis-Jordan wrote:
> > Both hw/input/hid.c and hw/usb/dev-wacom.c define identical versions
> > (aside from code formatting) of a clamping function, int_clamp().
> > (marked inline) To avoid duplication and to enable further re-use, this
> > change moves the function into qemu/cutils.h.
>
> Wht about replacing int_clamp(a, b, c) with MIN(MAX(a, b), c)?
> MIN(MAX(a, b), c) has a few advantages:
> - It works with any integer types
>(so you can replace even uint_clamp() in hw/display/vga.c)

Well, that can of course also be achieved by wrapping MIN(MAX(v, min),
max) in a new CLAMP(v, min, max) macro.

> - It makes clear that b is the minimum value and c is the maximum value
>while it is not with int_clamp()

I guess this aspect is rather subjective. When I see a MIN(MAX(
construct I generally feel the need to triple-check to make sure which
way around it is. (The minimum value is passed to MAX, the maximum to
MIN.)

On the other hand, there is precedent and convention for a clamp()
function with that order of parameters in other APIs and programming
languages: C++ std::clamp, Java Math.clamp(), OpenCL kernels and
OpenGL shaders can both use a built-in clamp() function, etc.

> - It is already used in other places.


The CLAMP macro would be my preferred compromise, although I don't
know how keen everyone is on introducing a new macro named after a
short, generic word.

[marxmail] Increased mistrust of the US medical profession and higher mortality rates are two consequences of the lack of Black doctors.

[Dennis Brasky]

Only 1.8% of US doctors were Black in 1906 – and the legacy of inequality
in medical education has not yet been erased

https://theconversation.com/only-1-8-of-us-doctors-were-black-in-1906-and-the-legacy-of-inequality-in-medical-education-has-not-yet-been-erased-219381


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30702): https://groups.io/g/marxmail/message/30702
Mute This Topic: https://groups.io/mt/106583399/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] How Israel’s Illiberal Democracy Became a Model for the Right - Dissent Magazine

[Dennis Brasky]

>
> In the fall of 1948, a German-born Zionist named Leo Kohn, who had earlier
>> published a study of the constitution adopted by the Irish Free State, was
>> putting the finishing touches on one such option. His draft constitution
>> would establish equal protection under the law; ban discrimination on the
>> basis of race, religion, language, or sex; institute equal civic and
>> political rights in employment and political office; and forbid the
>> expropriation of land or property “except for public purposes” subject to
>> full compensation. In short, it was a liberal-democratic constitution—the
>> precise thing that Ben-Gurion rejected.
>>
>> But in December of that year, the Israeli government enacted the
>> Emergency Regulations on Property of Absentees, creating a legal mechanism
>> to justify Palestinian dispossession. Designating as “absentee” any
>> non-Jewish person who had left their home and entered enemy territory
>> (which included much of Mandate Palestine) between November 29, 1947 and
>> September 1, 1948, the regulation expropriated homes and properties at a
>> massive scale—“more than 10,000 shops, 25,000 buildings (housing 57,000
>> family dwellings), and nearly 60 percent of all fertile land in the
>> country,” according to historian Shira Robinson
>> . This came on the heels of
>> Operation Hiram, a military campaign to conquer the central and northern
>> Galilee, which involved another round of expulsions aided by roughly a
>> dozen massacres in Palestinian villages. The Arab inhabitants who managed
>> to remain *in situ *were soon subjected to martial law—a condition that
>> would last until 1966.
>>
>> 
>
>
>
>>
>> https://www.dissentmagazine.org/article/how-israels-illiberal-democracy-became-a-model-for-the-right/
>>
>>
>>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30701): https://groups.io/g/marxmail/message/30701
Mute This Topic: https://groups.io/mt/106581863/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] UN: Israel-caused Famine to encompass all Gaza by July, killing as many as 19,800 a Month

[Dennis Brasky]

A new joint report

from
the Food and Agriculture Organization and the World Food Program warns that
even as North Gaza is now facing famine, “it is highly likely that the rest
of the Gaza Strip would be facing a risk of famine through July 2024, in a
worst-case scenario.”

The International Medical Corps
,
an NGO working in Gaza alongside UNICEF and other organizations, reports
this week that “According to a recent needs assessment by the Global
Nutrition Cluster, the situation in Gaza is alarming: the ongoing conflict
has significantly worsened child malnutrition from a Global Acute
Malnutrition rate of 0.8% to 16% in northern Gaza and 7% in the rest of
Gaza.”

That “7% in the rest of Gaza” figure will skyrocket by July to levels
similar to what now exists in North Gaza.
https://www.juancole.com/2024/06/israel-encompass-killing.html


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30700): https://groups.io/g/marxmail/message/30700
Mute This Topic: https://groups.io/mt/106581708/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: New OpenSSL Releases

[Dennis Clarke via openssl-users]

On 5/30/24 11:15, Michael Wojcik via openssl-users wrote:

From: openssl-users  On Behalf Of Dennis
Clarke via openssl-users
Sent: Thursday, 30 May, 2024 07:29

OKay, thank you. I guess today is a good day to test on a few oddball
system architectures. I suspect there are very very few people out there
running actual HPE Itanium hardware or big-endian IBM POWER and that
often raises a few bugs that slip under the radar.


Itanium is rare (we've stopped supporting it)...


Well I can report only two tests fail :

Test Summary Report
---
04-test_bio_dgram.t   (Wstat: 256 (exited 1) Tests: 1 
Failed: 1)

  Failed test:  1
  Non-zero exit status: 1
65-test_cmp_client.t  (Wstat: 256 (exited 1) Tests: 2 
Failed: 1)

  Failed test:  1
  Non-zero exit status: 1
Files=312, Tests=3685, 18523 wallclock secs (46.06 usr  1.22 sys + 
18271.89 cusr 170.74 csys = 18489.91 CPU)

Result: FAIL


So that is pretty cool on an Itanium :

garak$
garak$ uname -a
Linux garak 6.6.30-gentoo-ia64 #1 SMP Tue May 14 20:07:58 UTC 2024 ia64 
Madison GenuineIntel GNU/Linux

garak$

Now I am going to go digging and see where those tests fail. May be
something trivial.

garak$
garak$ find . | grep 'test_bio_dgram'
./test-runs/test_bio_dgram
./test/recipes/04-test_bio_dgram.t
garak$
garak$ find . | grep 'test_cmp_client'
./test-runs/test_cmp_client
./test/recipes/65-test_cmp_client_data
./test/recipes/65-test_cmp_client_data/client.csr
./test/recipes/65-test_cmp_client_data/client.key
./test/recipes/65-test_cmp_client_data/server.key
./test/recipes/65-test_cmp_client_data/server.crt
./test/recipes/65-test_cmp_client_data/client.crt
./test/recipes/65-test_cmp_client.t
garak$

No obvious output log files there.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: [marxmail] Repression of Marxists in Ukraine – Freedom for Bohdan Syrotyuk!

[Dennis Brasky]

This coming from a "Marxist" who supported Biden 4 years ago and still does!
Chutzpah!!!


On Sun, Jun 9, 2024 at 8:18 AM John Reimann via groups.io <1999wildcat=
gmail@groups.io> wrote:

> You miss my point. Just because a parrot is taught to say "I am an eagle"
> doesn't make it an eagle. And just because somebody calls  himself a
> "Marxist" doesn't make him (or her) a Marxist. WSWS may call itself
> "Marxist", but support in practice for the fascist-connected Putin
> automatically disqualifies them from that category. Yet your article
> includes them in that category. I don't believe it. I also don't know who
> this guy is nor what his activities consisted of, and neither do you
> apparently. But in any case, to call him a "Marxist" sullies that name.
>
> John Reimann
>
> --
> *“Science and socialism go hand-in-hand.” *Felicity Dowling
> Check out:https:http://oaklandsocialist.com also on Facebook
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30692): https://groups.io/g/marxmail/message/30692
Mute This Topic: https://groups.io/mt/106556101/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

On 08/06/2024 11:07, Peter Gutmann wrote:

when the dominant platform only offers 25519 then the the only option 
you have (unless you want to do the HRR dance) is to select that, 
whether you want it or not.


The recently adopted Key Share Prediction draft [1] allows servers to 
signal which key shares they'd like to see.


[1] 
https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Bug#1072845: Blank pages since upgrade to WebKitGTK 2.44

[Dennis Camera]

Package: epiphany-browser
Version: 43.1-1
Severity: important

Dear maintainer,

since upgrading libwebkit2gtk-4.1-0 from version 2.42.5 to 2.44.2 I'm
having difficulty browsing the web using Epiphany 43.1 on
Debian bookworm (12.5).
Most web pages (except for some very trivial ones) don't render and
only a white canvas is shown.

I attached the output of webkit://gpu at the end of this e-mail.

Other applications also using WebKitGTK (namely Evolution) are not
affected (on my system at least) and still display HTML e-mail correctly.

As a workaround setting the WEBKIT_DISABLE_DMABUF_RENDERER=1
environment variable restores the display of web pages in the Epiphany
browser.

Thank you for investigating.

Kind regards,

Dennis


{
"Version Information": {
"WebKit version": "WebKitGTK 2.44.2 (tarball)",
"Operating system": "Linux 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.90-1 (2024-05-03) x86_64",
"Desktop": "MATE",
"Cairo version": "1.16.0 (build) 1.16.0 (runtime)",
"GStreamer version": "1.22.0 (build) GStreamer 1.22.0 (runtime)",
"GTK version": "3.24.38 (build) 3.24.38 (runtime)"
},
"Display Information": {
"Identifier": "1",
"Type": "X11",
"Screen geometry": "0,0 1440x900",
"Screen work area": "0,24 1440x852",
"Depth": "24",
"Bits per color component": "8",
"Font Scaling DPI": "96.0244140625",
"Screen DPI": "110.48275454819004",
"VBlank type": "Timer",
"VBlank refresh rate": "60Hz",
"DRM Device": "/dev/dri/card0",
"DRM Render Node": "/dev/dri/renderD128"
},
"API": "OpenGL (libepoxy)",
"Hardware Acceleration Information": {
"Policy": "on demand",
"WebGL enabled": "Yes",
"Renderer": "DMABuf (Supported buffers: Hardware, Shared Memory)",
"Native interface": "None"
},
"Hardware Acceleration Information (Render process)": {
"Platform": "GBM",
"GL_RENDERER": "NVAC",
"GL_VENDOR": "nouveau",
"GL_VERSION": "OpenGL ES 3.0 Mesa 22.3.6",
"GL_SHADING_LANGUAGE_VERSION": "OpenGL ES GLSL ES 3.00",
"GL_EXTENSIONS": "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_s3tc
GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc
GL_EXT_texture_format_BGRA GL_OES_compressed_ETC1_RGB8_texture
GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float
GL_OES_texture_float_linear GL_OES_texture_half_float
GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_EXT_draw_instanced
GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture
GL_AMD_performance_monitor GL_OES_packed_depth_stencil
GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render
GL_OES_get_program_binary GL_APPLE_texture_max_level
GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage
GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_EGL_sync GL_OES_vertex_array_object
GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean
GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers
GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil
GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range
GL_KHR_debug GL_KHR_texture_compression_astc_ldr
GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_color_buffer_float GL_EXT_debug_label GL_EXT_sRGB_write_control
GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix
GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_copy_image GL_EXT_draw_elements_base_vertex
GL_EXT_polygon_offset_clamp GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_NV_shader_noperspective_interpolation
GL_OES_copy_image GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_OES_texture_stencil8
GL_EXT_blend_func_extended GL_EXT_float_blend GL_EXT_texture_sRGB_R8
GL_EXT_texture_sRGB_RG8 GL_KHR_no_error
GL_KHR_texture_compression_astc_sliced_3d
GL_OES_EGL_image_external_essl3 GL_EXT_clip_cull_distance
GL_EXT_disjoint_timer_query GL_

Re: [PATCH] ui/cocoa: Use qemu_add_mouse_change_notifier

[Phil Dennis-Jordan]

This looks fine to me. I've tested it briefly with a graphical Linux
guest and some tracing in the notifyMouseModeChange on a macOS 13
host. When I hot-unplug the usb-tablet I get an absolute -> relative
notification; everything works in relative mode after hot-adding a USB
mouse. Hot-unplugging and replugging the tablet yields a relative ->
absolute notification, and pointer input continues to behave
correctly.

Reviewed-by: Phil Dennis-Jordan 
Tested-by: Phil Dennis-Jordan 

On Fri, 22 Mar 2024 at 11:55, Akihiko Odaki  wrote:
>
> This eliminates the polling in cocoa_refresh and implements the
> propagation of the mouse mode change from absolute to relative.
>
> Signed-off-by: Akihiko Odaki 
> ---
>  ui/cocoa.m | 62 
> ++
>  1 file changed, 38 insertions(+), 24 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 810751cf2644..b53920b8814c 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -310,6 +310,14 @@ @interface QemuCocoaView : NSView
>  NSTrackingArea *trackingArea;
>  QEMUScreen screen;
>  pixman_image_t *pixman_image;
> +/* The state surrounding mouse grabbing is potentially confusing.
> + * isAbsoluteEnabled tracks qemu_input_is_absolute() [ie "is the emulated
> + *   pointing device an absolute-position one?"], but is only updated on
> + *   next refresh.
> + * isMouseGrabbed tracks whether GUI events are directed to the guest;
> + *   it controls whether special keys like Cmd get sent to the guest,
> + *   and whether we capture the mouse when in non-absolute mode.
> + */
>  BOOL isMouseGrabbed;
>  BOOL isAbsoluteEnabled;
>  CFMachPortRef eventsTap;
> @@ -321,17 +329,8 @@ - (void) setFullGrab:(id)sender;
>  - (void) handleMonitorInput:(NSEvent *)event;
>  - (bool) handleEvent:(NSEvent *)event;
>  - (bool) handleEventLocked:(NSEvent *)event;
> -- (void) setAbsoluteEnabled:(BOOL)tIsAbsoluteEnabled;
> -/* The state surrounding mouse grabbing is potentially confusing.
> - * isAbsoluteEnabled tracks qemu_input_is_absolute() [ie "is the emulated
> - *   pointing device an absolute-position one?"], but is only updated on
> - *   next refresh.
> - * isMouseGrabbed tracks whether GUI events are directed to the guest;
> - *   it controls whether special keys like Cmd get sent to the guest,
> - *   and whether we capture the mouse when in non-absolute mode.
> - */
> +- (void) notifyMouseModeChange;
>  - (BOOL) isMouseGrabbed;
> -- (BOOL) isAbsoluteEnabled;
>  - (QEMUScreen) gscreen;
>  - (void) raiseAllKeys;
>  @end
> @@ -437,6 +436,7 @@ - (void) selectConsoleLocked:(unsigned int)index
>  qkbd_state_switch_console(kbd, con);
>  dcl.con = con;
>  register_displaychangelistener();
> +[self notifyMouseModeChange];
>  [self updateUIInfo];
>  }
>
> @@ -1103,14 +1103,26 @@ - (void) ungrabMouse
>  [self raiseAllButtons];
>  }
>
> -- (void) setAbsoluteEnabled:(BOOL)tIsAbsoluteEnabled {
> +- (void) notifyMouseModeChange {
> +bool tIsAbsoluteEnabled = bool_with_bql(^{
> +return qemu_input_is_absolute(dcl.con);
> +});
> +
> +if (tIsAbsoluteEnabled == isAbsoluteEnabled) {
> +return;
> +}
> +
>  isAbsoluteEnabled = tIsAbsoluteEnabled;
> +
>  if (isMouseGrabbed) {
> -CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
> +if (isAbsoluteEnabled) {
> +[self ungrabMouse];
> +} else {
> +CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
> +}
>  }
>  }
>  - (BOOL) isMouseGrabbed {return isMouseGrabbed;}
> -- (BOOL) isAbsoluteEnabled {return isAbsoluteEnabled;}
>  - (QEMUScreen) gscreen {return screen;}
>
>  /*
> @@ -1784,6 +1796,17 @@ static void addRemovableDevicesMenuItems(void)
>  qapi_free_BlockInfoList(pointerToFree);
>  }
>
> +static void cocoa_mouse_mode_change_notify(Notifier *notifier, void *data)
> +{
> +dispatch_async(dispatch_get_main_queue(), ^{
> +[cocoaView notifyMouseModeChange];
> +});
> +}
> +
> +static Notifier mouse_mode_change_notifier = {
> +.notify = cocoa_mouse_mode_change_notify
> +};
> +
>  @interface QemuCocoaPasteboardTypeOwner : NSObject
>  @end
>
> @@ -1968,17 +1991,6 @@ static void cocoa_refresh(DisplayChangeListener *dcl)
>  COCOA_DEBUG("qemu_cocoa: cocoa_refresh\n");
>  graphic_hw_update(dcl->con);
>
> -if (qemu_input_is_absolute(dcl->con)) {
> -dispatch_async(dispatch_get_main_queue(), ^{
> -if (![cocoaView isAbsoluteEnabled]) {
> -if ([cocoaView isMouseGrabbed]) {
> -   

[PATCH 2/3] hw: Moves int_clamp() implementations to header

[Phil Dennis-Jordan]

Both hw/input/hid.c and hw/usb/dev-wacom.c define identical versions
(aside from code formatting) of a clamping function, int_clamp().
(marked inline) To avoid duplication and to enable further re-use, this
change moves the function into qemu/cutils.h.

Signed-off-by: Phil Dennis-Jordan
---
 hw/input/hid.c| 12 +---
 hw/usb/dev-wacom.c| 11 +--
 include/qemu/cutils.h | 11 +++
 3 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/hw/input/hid.c b/hw/input/hid.c
index 76bedc1844..89f37f1bbb 100644
--- a/hw/input/hid.c
+++ b/hw/input/hid.c
@@ -26,6 +26,7 @@
 #include "qemu/osdep.h"
 #include "ui/console.h"
 #include "qemu/timer.h"
+#include "qemu/cutils.h"
 #include "hw/input/hid.h"
 #include "migration/vmstate.h"
 #include "trace.h"
@@ -336,17 +337,6 @@ static void hid_keyboard_process_keycode(HIDState *hs)
 }
 }
 
-static inline int int_clamp(int val, int vmin, int vmax)
-{
-if (val < vmin) {
-return vmin;
-} else if (val > vmax) {
-return vmax;
-} else {
-return val;
-}
-}
-
 void hid_pointer_activate(HIDState *hs)
 {
 if (!hs->ptr.mouse_grabbed) {
diff --git a/hw/usb/dev-wacom.c b/hw/usb/dev-wacom.c
index 7177c17f03..539581010e 100644
--- a/hw/usb/dev-wacom.c
+++ b/hw/usb/dev-wacom.c
@@ -32,6 +32,7 @@
 #include "hw/usb/hid.h"
 #include "migration/vmstate.h"
 #include "qemu/module.h"
+#include "qemu/cutils.h"
 #include "desc.h"
 #include "qom/object.h"
 
@@ -215,16 +216,6 @@ static void usb_wacom_event(void *opaque,
 usb_wakeup(s->intr, 0);
 }
 
-static inline int int_clamp(int val, int vmin, int vmax)
-{
-if (val < vmin)
-return vmin;
-else if (val > vmax)
-return vmax;
-else
-return val;
-}
-
 static int usb_mouse_poll(USBWacomState *s, uint8_t *buf, int len)
 {
 int dx, dy, dz, b, l;
diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
index da15547bfb..4394f03326 100644
--- a/include/qemu/cutils.h
+++ b/include/qemu/cutils.h
@@ -277,6 +277,17 @@ static inline const char *yes_no(bool b)
  return b ? "yes" : "no";
 }
 
+static inline int int_clamp(int val, int vmin, int vmax)
+{
+if (val < vmin) {
+return vmin;
+} else if (val > vmax) {
+return vmax;
+} else {
+return val;
+}
+}
+
 /*
  * helper to parse debug environment variables
  */
-- 
2.36.1

[PATCH 1/3] Cursor: 8 -> 1 bit alpha downsampling improvement

[Phil Dennis-Jordan]

Mouse cursors with 8 bit alpha were downsampled to 1-bit opacity maps by
turning alpha values of 255 into 1 and everything else into 0. This
means that mostly-opaque pixels ended up completely invisible.

This patch changes the behaviour so that only pixels with less than 50%
alpha (0-127) are treated as transparent when converted to 1-bit alpha.

This greatly improves the subjective appearance of anti-aliased mouse
cursors, such as those used by macOS, when using a front-end UI without
support for alpha-blended cursors, such as some VNC clients.

Signed-off-by: Phil Dennis-Jordan 
---
 ui/cursor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/cursor.c b/ui/cursor.c
index 29717b3ecb..4c05ec 100644
--- a/ui/cursor.c
+++ b/ui/cursor.c
@@ -232,7 +232,7 @@ void cursor_get_mono_mask(QEMUCursor *c, int transparent, 
uint8_t *mask)
 for (y = 0; y < c->height; y++) {
 bit = 0x80;
 for (x = 0; x < c->width; x++, data++) {
-if ((*data & 0xff00) != 0xff00) {
+if ((*data & 0xff00) < 0x8000) {
 if (transparent != 0) {
 mask[x/8] |= bit;
 }
-- 
2.36.1

[PATCH 3/3] ui/cocoa: Adds support for mouse cursors

[Phil Dennis-Jordan]

This change implements the callbacks dpy_cursor_define and dpy_mouse_set
for the Cocoa UI. The incoming mouse cursor image is converted into an
NSCursor object, allowing the guest mouse cursor to be rendered as the
host's native OS cursor on macOS.

This is straightforward in absolute pointing mode, but rather trickier
with a relative pointing device:

 1. The cursor position in Qemu's coordinate system must be translated
and converted into macOS's Core Graphics/Quartz coordinates when
positioning the cursor. Additionally, the position already includes
the hotspot offset; we'd prefer to use the host OS's hotspot support
so we need subtract the hotspot vector off again.
 2. Setting the cursor position programmatically on macOS biases the
next mouse movement event by the amount the cursor was shifted.
If we didn't reverse that bias when forwarding the next event
back into Qemu's input stack, this would create a feedback loop.
(The behaviour of affecting mouse events makes sense for e.g.
setting the cursor position in a remote access system.)

This change slightly improves the user experience when using virtual
display adapter implementations which check for UI back-end cursor
support, and fixes the issue of no visible mouse cursor when using one
which does not. (Such as virtio-vga)

Signed-off-by: Phil Dennis-Jordan 
---
 ui/cocoa.m  | 167 +++-
 ui/trace-events |   7 ++
 2 files changed, 171 insertions(+), 3 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 981615a8b9..0c71533835 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -49,6 +49,7 @@
 #include "qemu/error-report.h"
 #include 
 #include "hw/core/cpu.h"
+#include "trace.h"
 
 #ifndef MAC_OS_VERSION_14_0
 #define MAC_OS_VERSION_14_0 14
@@ -80,11 +81,17 @@ static void cocoa_switch(DisplayChangeListener *dcl,
 
 static void cocoa_refresh(DisplayChangeListener *dcl);
 
+static void cocoa_cursor_define(DisplayChangeListener *dcl, QEMUCursor 
*cursor);
+
+static void cocoa_mouse_set(DisplayChangeListener *dcl, int x, int y, int on);
+
 static const DisplayChangeListenerOps dcl_ops = {
 .dpy_name  = "cocoa",
 .dpy_gfx_update = cocoa_update,
 .dpy_gfx_switch = cocoa_switch,
 .dpy_refresh = cocoa_refresh,
+.dpy_cursor_define = cocoa_cursor_define,
+.dpy_mouse_set = cocoa_mouse_set,
 };
 static DisplayChangeListener dcl = {
 .ops = _ops,
@@ -299,6 +306,11 @@ @interface QemuCocoaView : NSView
 BOOL isMouseGrabbed;
 BOOL isAbsoluteEnabled;
 CFMachPortRef eventsTap;
+NSCursor *current_cursor;
+int cursor_hot_x;
+int cursor_hot_y;
+int offset_delta_x;
+int offset_delta_y;
 }
 - (void) switchSurface:(pixman_image_t *)image;
 - (void) grabMouse;
@@ -320,6 +332,9 @@ - (BOOL) isMouseGrabbed;
 - (BOOL) isAbsoluteEnabled;
 - (QEMUScreen) gscreen;
 - (void) raiseAllKeys;
+- (void) setCursor:(NSCursor*)newCursor hotspotX:(int)hotX y:(int)hotY;
+- (void) setMouseX:(int)x y:(int)y showCursor:(BOOL)showCursor;
+
 @end
 
 QemuCocoaView *cocoaView;
@@ -376,6 +391,9 @@ - (void) dealloc
 pixman_image_unref(pixman_image);
 }
 
+[self->current_cursor release];
+self->current_cursor = nil;
+
 if (eventsTap) {
 CFRelease(eventsTap);
 }
@@ -407,6 +425,68 @@ - (void) selectConsoleLocked:(unsigned int)index
 [self updateUIInfo];
 }
 
+- (void) setCursor:(NSCursor*)newCursor hotspotX:(int)hotX y:(int)hotY
+{
+[self->current_cursor release];
+[newCursor retain];
+self->current_cursor = newCursor;
+
+cocoaView->cursor_hot_x = hotX;
+cocoaView->cursor_hot_y = hotY;
+
+[self.window invalidateCursorRectsForView:self];
+}
+
+- (void) resetCursorRects
+{
+if (self->current_cursor == nil) {
+[super resetCursorRects];
+} else {
+[self addCursorRect:NSMakeRect(0.0, 0.0, self->screen.width, 
self->screen.height) cursor:self->current_cursor];
+}
+}
+
+- (void) setMouseX:(int)x y:(int)y showCursor:(BOOL)showCursor
+{
+if (isAbsoluteEnabled) {
+offset_delta_x = 0;
+offset_delta_y = 0;
+return;
+} else if (!isMouseGrabbed) {
+return;
+}
+
+NSWindow* window = [self window];
+
+/* Coordinates seem to come in already offset by hotspot; undo that. Also
+ * avoid out-of-window coordinates. */
+x += cursor_hot_x;
+y += cursor_hot_y;
+x = int_clamp(x, 0, screen.width);
+y = int_clamp(y, 0, screen.height);
+/* Flip coordinates so origin is bottom left (Cocoa), not top left (Qemu),
+ * before translating into window and then desktop coordinate systems. */
+y = screen.height - y;
+
+NSPoint new_pos_window = [self convertPoint:NSMakePoint(x, y) toView:nil];
+NSPoint prev_pos_window = window.mouseLocationOutsideOfEventStream;
+
+CGPoint screen_pos = [window convertPointToScreen:new_pos_window];

[PATCH 0/3] Mouse cursor improvements on macOS and VNC

[Phil Dennis-Jordan]

This series of loosely related changes provides some minor improvements
in mouse cursor usability.

 1. This one-liner changes alpha downsampling when using a UI frontend
which does not support alpha-blended mouse cursors. Previously,
any pixel with an alpha value other than 255 was treated as fully
transparent in this context. This looks pretty bad when the guest
OS uses anti-aliased cursors. (e.g. macOS) This occurs with some
VNC clients, for example.
 2. This change has nothing to do with cursors: there are two
functionally identical implementations of an int_clamp() inline
function in the Qemu codebase. This unifies them in the shared
cutils.h header, as I'm about to use it in a third location in
patch number 3.
 3. This sizeable patch implements cursor support in the (macOS) Cocoa
UI frontend. This fixes the issue of no mouse pointer showing up
when using virtio-vga on a macOS host, for example.
It unfortunately introduces some complexity to the mouse movement
event handling when using a relative pointing device in the guest,
as teleporting the cursor on the host offsets the next mouse event
delta by a corresponding amount. We therefore need to track this
offset and counteract it when processing the event. For details,
see the commit message and inline comments.

This work was sponsored by Sauce Labs Inc.

Phil Dennis-Jordan (3):
  Cursor: 8 -> 1 bit alpha downsampling improvement
  hw: Moves int_clamp() implementations to header
  ui/cocoa: Adds support for mouse cursors

 hw/input/hid.c|  12 +--
 hw/usb/dev-wacom.c|  11 +--
 include/qemu/cutils.h |  11 +++
 ui/cocoa.m| 167 +-
 ui/cursor.c   |   2 +-
 ui/trace-events   |   7 ++
 6 files changed, 185 insertions(+), 25 deletions(-)

-- 
2.36.1

[marxmail] Lebanon’s Hezbollah is proving to be a serious Problem for Israel

[Dennis Brasky]

Hezbollah intensified its attacks in northern Israel on June 2, firing
barrages of rockets over the border that set off massive wildfires
. This came two days after the
Lebanese armed group revealed

that
it had downed one of Israel’s most advanced drones – the most recent of
several successful air defence operations.

The events of October 7 had already marked the collapse

of
Israel’s national security doctrine. Three of the four components –
deterrence, early warning and defence – had failed completely. The conflict
with Hezbollah, which Israel has been fighting alongside its war on Gaza,
continues to damage these beyond repair.

Hezbollah, which is part of the broader Iranian-backed “axis of resistance”
with the Ansarullah (commonly known as the Houthi) movement in Yemen and
other groups in Syria and Iraq, has demonstrated its developing military,
intelligence and media capabilities since the start of Israel’s war on Gaza.

The group has gradually introduced new missiles to the conflict that are
more precise and destructive. And it has also demonstrated its ability to
identify weaknesses in Israel’s air defence systems, generate targets
and execute
complex operations

almost
daily.

https://www.juancole.com/2024/06/lebanons-hezbollah-proving.html


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30686): https://groups.io/g/marxmail/message/30686
Mute This Topic: https://groups.io/mt/106565154/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Bug#1070972: epiphany-browser fails to render webpages - blank pages

[Dennis Camera]

Control: found 1070972 epiphany-browser/43.1-1

Hi,

I am seeing the same bug with Epiphany 43.1 on Debian bookworm (12.5)
since upgrading libwebkit2gtk-4.1-0 from version 2.42.5 to 2.44.2.

I attached the output of webkit://gpu at the end of this e-mail.

Other applications also using WebKitGTK (namely Evolution) are not
affected (on my system at least) and still display HTML e-mail correctly.

As a workaround setting the WEBKIT_DISABLE_DMABUF_RENDERER=1
environment variable restores the display of web pages in the Epiphany
browser.

Kind regards,

Dennis


{
"Version Information": {
"WebKit version": "WebKitGTK 2.44.2 (tarball)",
"Operating system": "Linux 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.90-1 (2024-05-03) x86_64",
"Desktop": "MATE",
"Cairo version": "1.16.0 (build) 1.16.0 (runtime)",
"GStreamer version": "1.22.0 (build) GStreamer 1.22.0 (runtime)",
"GTK version": "3.24.38 (build) 3.24.38 (runtime)"
},
"Display Information": {
"Identifier": "1",
"Type": "X11",
"Screen geometry": "0,0 1440x900",
"Screen work area": "0,24 1440x852",
"Depth": "24",
"Bits per color component": "8",
"Font Scaling DPI": "96.0244140625",
"Screen DPI": "110.48275454819004",
"VBlank type": "Timer",
"VBlank refresh rate": "60Hz",
"DRM Device": "/dev/dri/card0",
"DRM Render Node": "/dev/dri/renderD128"
},
"API": "OpenGL (libepoxy)",
"Hardware Acceleration Information": {
"Policy": "on demand",
"WebGL enabled": "Yes",
"Renderer": "DMABuf (Supported buffers: Hardware, Shared Memory)",
"Native interface": "None"
},
"Hardware Acceleration Information (Render process)": {
"Platform": "GBM",
"GL_RENDERER": "NVAC",
"GL_VENDOR": "nouveau",
"GL_VERSION": "OpenGL ES 3.0 Mesa 22.3.6",
"GL_SHADING_LANGUAGE_VERSION": "OpenGL ES GLSL ES 3.00",
"GL_EXTENSIONS": "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_s3tc
GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc
GL_EXT_texture_format_BGRA GL_OES_compressed_ETC1_RGB8_texture
GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float
GL_OES_texture_float_linear GL_OES_texture_half_float
GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_EXT_draw_instanced
GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture
GL_AMD_performance_monitor GL_OES_packed_depth_stencil
GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render
GL_OES_get_program_binary GL_APPLE_texture_max_level
GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage
GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_EGL_sync GL_OES_vertex_array_object
GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean
GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers
GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil
GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range
GL_KHR_debug GL_KHR_texture_compression_astc_ldr
GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_color_buffer_float GL_EXT_debug_label GL_EXT_sRGB_write_control
GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix
GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_copy_image GL_EXT_draw_elements_base_vertex
GL_EXT_polygon_offset_clamp GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_NV_shader_noperspective_interpolation
GL_OES_copy_image GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_OES_texture_stencil8
GL_EXT_blend_func_extended GL_EXT_float_blend GL_EXT_texture_sRGB_R8
GL_EXT_texture_sRGB_RG8 GL_KHR_no_error
GL_KHR_texture_compression_astc_sliced_3d
GL_OES_EGL_image_external_essl3 GL_EXT_clip_cull_distance
GL_EXT_disjoint_timer_query GL_EXT_texture_compression_s3tc_srgb
GL_EXT_window_rectangles GL_MESA_shader_integer_functions
GL_EXT_clip_control GL_EXT_color_buffer_half_float
GL_EXT_textur

Re: 29 failed tests in the Texinfo 7.1 testsuite on Debian with IBM POWER9

[Dennis Clarke via Bug reports for the GNU Texinfo documentation system]

On 6/3/24 05:03, Patrice Dumas wrote:

On Sun, Jun 02, 2024 at 02:31:11PM -0400, Dennis Clarke wrote:

The patch works !


Thanks for the report!

@Gavin: this could go in 7.1 bugfix release, although with the upcoming
release it may not be needed.



So then, can we expect a trivial rev update to 7.1.1 at the very least?

In the short term I mean.




--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

[marxmail] The International Order Is Failing to Protect Palestinian Cultural Heritage

[Dennis Brasky]

As Israeli forces destroy sites and monuments in Gaza, an archaeologist
explains how international organizations charged with protecting cultural
heritage should intervene—but have not.

https://www.sapiens.org/archaeology/cultural-heritage-gaza-destruction/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30670): https://groups.io/g/marxmail/message/30670
Mute This Topic: https://groups.io/mt/106553843/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[Bug 2064208] Re: Installer crashes when booting from USB on Raspberry Pi

[Dennis Golden]

*** This bug is a duplicate of bug 2037015 ***
https://bugs.launchpad.net/bugs/2037015

In regards to my previous comment, if it is inappropriate to post here,
please direct my to the proper place.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064208

Title:
  Installer crashes when booting from USB on Raspberry Pi

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/2064208/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064208] Re: Installer crashes when booting from USB on Raspberry Pi

[Dennis Golden]

*** This bug is a duplicate of bug 2037015 ***
https://bugs.launchpad.net/bugs/2037015

I know that this has been marked as a duplicate to bug#2037015, but I
see nothing in the comments of that bug that talks about the
availability of a raspberry pi installation source. I have tried the
official images, but they fail. The only one I have been able to
successfully install is
"https://zoidberg.waveform.org.uk/images/ubuntu-24.04-preinstalled-
desktop-arm64+raspi.img.xz" referred to in comment #1 above.

Will there be an official installation image available for the Raspberry
Pi? If so, when.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064208

Title:
  Installer crashes when booting from USB on Raspberry Pi

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/2064208/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2068658] [NEW] abiquity crash during new installation

[Dennis Golden]

Public bug reported:

I don't have any other information... this was install from scratch.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: ubiquity 24.04.5
ProcVersionSignature: Ubuntu 6.8.0-1004.4-raspi 6.8.1
Uname: Linux 6.8.0-1004-raspi aarch64
ApportVersion: 2.28.1-0ubuntu2
Architecture: arm64
CasperMD5CheckResult: unknown
CloudArchitecture: aarch64
CloudID: none
CloudName: none
CloudPlatform: none
CloudSubPlatform: config
CurrentDesktop: ubuntu:GNOME
Date: Thu Jun  6 14:05:16 2024
ProcEnviron:
 LANG=en_US.UTF-8
 LC_NUMERIC=C.UTF-8
 PATH=(custom, no user)
 TERM=linux
 XDG_RUNTIME_DIR=
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: ubiquity (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: apport-bug arm64 noble

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068658

Title:
  abiquity crash during new installation

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/2068658/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[marxmail] Never forget the 2018–2019 Gaza border protests, also known as the Great March of Return

[Dennis Brasky]

The 2018–2019 Gaza border protests, also known as the Great March of
Return, were a series of demonstrations held each Friday in the Gaza Strip
near the Gaza-Israel border from 30 March 2018 until 27 December 2019, in
which Israeli forces killed a total of 223 Palestinians.

https://en.wikipedia.org/wiki/2018%E2%80%932019_Gaza_border_protests#:


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30652): https://groups.io/g/marxmail/message/30652
Mute This Topic: https://groups.io/mt/106526644/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] The anti-war left makes inroads in Israel

[Dennis Brasky]

Standing Together’s national field organizer Uri Weltmann discusses the
growing peace movement inside Israel, confronting far-right extremists
seeking to disrupt humanitarian aid going to the Gaza Strip, and the left’s
recent electoral breakthroughs

https://links.org.au/anti-war-left-makes-inroads-israel-interview-standing-togethers-uri-weltmann

I have my doubts about this but would love to be proven wrong!


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30651): https://groups.io/g/marxmail/message/30651
Mute This Topic: https://groups.io/mt/106526188/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [PATCH v3 0/7] hvf x86 correctness and efficiency improvements

[Phil Dennis-Jordan]

On Thu, 6 Jun 2024 at 10:24, Paolo Bonzini  wrote:
> Queued, thanks.

Thanks - also for reviewing, etc.!

> Thanks for persisting!  It sucks that the hv_vcpu_interrupt() API docs
> are not clear, but your tests are great.  The self-interrupt one is
> the case that I was most worried about, and you're covering it.
> Sorry for being a pain for nothing, at least retrospectively.

No worries - the concern is understandable, especially in the face of
the unfortunate apparent regression which turned out to be the dirty
page tracking bug.

And I agree, the hv_vcpu_interrupt docs, along with the rest of
Hypervisor.framework's, are terrible. There does not appear to have
been any thought about what a developer using that API might care
about. I've been working on integrating the HVF APIC/PIC/IOAPIC
implementations, and there are ambiguities and edge cases galore.
Unfortunately (?), the perf improvement is worth the trouble of trial
& error…


Phil

[marxmail] Israel advances displacement campaign across Jerusalem, West Bank

[Dennis Brasky]

On Wed, Jun 5, 2024 at 12:11 PM Cody O'Rourke <
c...@goodshepherdcollective.org> wrote:

> Unsubscribe here
> 
> Weekly Report
> A critical update from the Good Shepherd Collective
> Israel carries out mass displacement across Jerusalem, West Bank
>
> The Supreme Court has ordered the Shehadeh family to be evicted from their
> four-story home in Batan al-Hawa, Silwan, by June 1, 2024, in favor of
> settlers affiliated with the Ateret Cohanim organization. The family's
> petition challenged this decision, citing procedural flaws. It didn't
> matter. On May 26, 2024, the Israeli kangaroo courts rejected their
> petition, exhausting all legal avenues.
>
> If the Shehadehs do not leave their home, settlers will initiate
> procedures with the Execution Office to evict them, coordinated with the
> Israeli police to use force to displace this family. Over 80 Palestinian
> families face similar eviction cases, risking the displacement of hundreds
> of Palestinians from their homes in East Jerusalem to be replaced by
> Israeli settlers. This underscores the power that settler groups like
> Ateret Cohanim have to use Israel's colonial system to dispossess
> Palestinians from their properties and lands.
>
> From January 1, 2024, Israel has increased the number of demolition
> operations across East Jerusalem and the West Bank, resulting in a
> significant increase in displacement and structural damage. A total of 82
> households have been displaced, with 881 households otherwise affected. In
> terms of people, 394 Palestinians have been displaced, and 44,454 have been
> affected as a result of disruption in work, education, and health impact.
> As Israel eyes the annexation of the West Bank seeking the greatest amount
> of land with the least number of Palestinians, home demolitions continue to
> be a critical tool to enact this vision. A total of 88 inhabited
> residential structures, 34 uninhabited residential structures, 133
> agricultural structures, and 90 livelihood structures have been demolished
> since the beginning of 2024. Additionally, 28 WASH (Water, Sanitation, and
> Hygiene) structures, seven infrastructure structures, and 14 other types of
> structures have also been destroyed. This data underscores how Israel's
> policies of apartheid and ethnic cleansing are being animated in real time
> — with very few consequences.
>
> Ateret Cohanim
> ,
> which filed these eviction demands, receives charitable donations through
> the American Friends of Ateret Cohanim / Jerusalem Chai, a charity
> registered in New York, US.
>
> View online
> 
> Demolition Data
> `Total` represents the daily count for the last 365 days
> Displaced People
> Total 10 day avg 90 day avg Trend
> 1035 4.5[image: Arrow Trend] 2.04 [image: Displaced People graph]
> Structures
> Total 10 day avg 90 day avg Trend
> 913 2.6[image: Arrow Trend] 2.07 [image: Structures graph]
> Men Displaced
> Total 10 day avg 90 day avg Trend
> 275 1[image: Arrow Trend] 0.49 [image: Men Displaced graph]
> Women Displaced
> Total 10 day avg 90 day avg Trend
> 256 1.4[image: Arrow Trend] 0.5 [image: Women Displaced graph]
> Children Displaced
> Total 10 day avg 90 day avg Trend
> 504 2.1[image: Arrow Trend] 1.09 [image: Children Displaced graph]
> DOWNLOAD IMAGE
> 
> | DOWNLOAD .CSV
> 
> | DOWNLOAD .XLSX
> 
> Notes
>
> This data set runs from 06.07.2023 to today, with the 90 day demarcation
> being 03.07.2024 and the 10 day mark being set at 05.26.2024. This data for
> for the last 365 days, not Year-to-Date. And as the data points out, across
> Jerusalem and the West Bank, displacement has been trending upwords. This,
> of course, is by design.
>
> This data only reflects administrative home demolitions
> 
> in East Jerusalem and the West Bank. This doesn't include the mass
> demolitions of homes in the Gaza Strip, or in places like the Naqab or the
> Galilee
> Gaza Data
>
> Since October 7, 2023, Israel has killed at least 36,586 Palestinians
> across Gaza. During its campaign to ethnically cleanse Gaza, through
> indiscriminate bombings, some 83,074 individuals have been 

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

Hi Peter, Mike

Peter Gutmann wrote:


Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
can't reformat your hard drive, for example, so presumably that's OK too).
The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.


As Nick quoted from the spec:


A TLS-compliant application MUST support key exchange with secp256r1 (NIST 
P-256)
Chrome advertises support for P-256 in the supported groups extension. 
As a factual matter, Chrome can successfully connect to a site that only 
implements support for P-256. I cannot find any basis for Peter's claims 
in the spec.


Ekr wrote:


One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the 
key_shares

of their initial CH, then that would be a straightforward text change.


I think we are closer to going in the other direction and allow TLS1.3 
spec-compliant implementations aiming at post-quantum support to drop 
support for P-256 entirely.


Best,
Dennis

On 05/06/2024 14:34, Peter Gutmann wrote:

Mike Shaver  writes:


You mentioned in another message that some embedded TLS implementations also
omit MTI support for code size or attack surface reasons.

They don't omit MTI support, they *only* support MTI (think Grigg's Law,
"there is only one mode and that is secure").  So when faced with an
implementation that doesn't, they can't talk to each other.


do you have any sense of why Chrome chose to omit this MTI support?

I suspect it's just because Google does whatever Google wants to (see e.g.
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/,
section "The Warnings").  This may not be politically expendient to say out
loud :-).

Peter.
___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[marxmail] How We’ve Failed the Promise of Making “Genocide” a Crime

[Dennis Brasky]

The lawyer Raphael Lemkin hoped to use international law to curb abuses of
power. But his efforts were curtailed from the start.

https://www.motherjones.com/politics/2024/06/israel-palestine-gaza-genocide-war-crimes-icj-south-africa-raphael-lemkin/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30639): https://groups.io/g/marxmail/message/30639
Mute This Topic: https://groups.io/mt/106502996/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[PATCH v3 0/7] hvf x86 correctness and efficiency improvements

[Phil Dennis-Jordan]

 a classic assertion, reporting the
expression as well as the source code location along with the error.

changelog:
v3:
 - Back to one patch series with all the changes.
 - Detailed investigation into edge case behaviour of hv_vcpu_interrupt.
   Determined it was behaving fine, no race condition workarounds needed,
   so the kick and hv_vcpu_run_until patches have actually stayed essentially
   the same as in v1.
 - Added the assert_hvf_ok patch because I kept using it when debugging.

v2:
 - Migration blocker when INVTSC is set (Thanks Paolo for pointing that out!)
 - Dirty page tracking fix (Thanks Roman for noticing the regression in
   observed behaviour on certain VMs, which led me to debugging this issue.)
 - vCPU handle type cleanup (Based on discussion with Paolo)
 - Added fixes for existing compile warnings.
 - Split patch series into 2 parts.

This work has been sponsored by Sauce Labs Inc.

Phil Dennis-Jordan (7):
  i386/hvf: Adds support for INVTSC cpuid bit
  i386/hvf: Fixes some compilation warnings
  hvf: Consistent types for vCPU handles
  i386/hvf: Fixes dirty memory tracking by page granularity RX->RWX
change
  i386/hvf: In kick_vcpu use hv_vcpu_interrupt to force exit
  i386/hvf: Updates API usage to use modern vCPU run function
  hvf: Makes assert_hvf_ok report failed expression

 accel/hvf/hvf-accel-ops.c|  2 +-
 accel/hvf/hvf-all.c  | 49 
 include/sysemu/hvf_int.h |  9 +--
 target/i386/hvf/hvf.c| 47 +++---
 target/i386/hvf/vmx.h|  3 +--
 target/i386/hvf/x86_cpuid.c  |  4 +++
 target/i386/hvf/x86_decode.c |  2 +-
 target/i386/hvf/x86_emu.c|  4 +--
 8 files changed, 81 insertions(+), 39 deletions(-)

-- 
2.36.1

[PATCH v3 5/7] i386/hvf: In kick_vcpu use hv_vcpu_interrupt to force exit

[Phil Dennis-Jordan]

When interrupting a vCPU thread, this patch actually tells the hypervisor to
stop running guest code on that vCPU.

Calling hv_vcpu_interrupt actually forces a vCPU exit, analogously to
hv_vcpus_exit on aarch64. Alternatively, if the vCPU thread
is not
running the VM, it will immediately cause an exit when it attempts
to do so.

Previously, hvf_kick_vcpu_thread relied upon hv_vcpu_run returning very
frequently, including many spurious exits, which made it less of a problem that
nothing was actively done to stop the vCPU thread running guest code.
The newer, more efficient hv_vcpu_run_until exits much more rarely, so a true
"kick" is needed before switching to that.

Signed-off-by: Phil Dennis-Jordan 
---
 target/i386/hvf/hvf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index 268c5734d5..106ac5cbf6 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -215,6 +215,7 @@ static inline bool apic_bus_freq_is_known(CPUX86State *env)
 void hvf_kick_vcpu_thread(CPUState *cpu)
 {
 cpus_kick_thread(cpu);
+hv_vcpu_interrupt(>accel->fd, 1);
 }
 
 int hvf_arch_init(void)
-- 
2.36.1

[PATCH v3 7/7] hvf: Makes assert_hvf_ok report failed expression

[Phil Dennis-Jordan]

When a macOS Hypervisor.framework call fails which is checked by
assert_hvf_ok(), Qemu exits printing the error value, but not the
location
in the code, as regular assert() macro expansions would.

This change turns assert_hvf_ok() into a macro similar to other
assertions, which expands to a call to the corresponding _impl()
function together with information about the expression that failed
the assertion and its location in the code.

Additionally, stringifying the numeric hv_return_t code is factored
into a helper function that can be reused for diagnostics and debugging
outside of assertions.

Signed-off-by: Phil Dennis-Jordan 
---
 accel/hvf/hvf-all.c  | 49 +---
 include/sysemu/hvf_int.h |  5 +++-
 2 files changed, 25 insertions(+), 29 deletions(-)

diff --git a/accel/hvf/hvf-all.c b/accel/hvf/hvf-all.c
index db05b81be5..c008dc2f1e 100644
--- a/accel/hvf/hvf-all.c
+++ b/accel/hvf/hvf-all.c
@@ -13,40 +13,33 @@
 #include "sysemu/hvf.h"
 #include "sysemu/hvf_int.h"
 
-void assert_hvf_ok(hv_return_t ret)
+const char *hvf_return_string(hv_return_t ret)
 {
-if (ret == HV_SUCCESS) {
-return;
-}
-
 switch (ret) {
-case HV_ERROR:
-error_report("Error: HV_ERROR");
-break;
-case HV_BUSY:
-error_report("Error: HV_BUSY");
-break;
-case HV_BAD_ARGUMENT:
-error_report("Error: HV_BAD_ARGUMENT");
-break;
-case HV_NO_RESOURCES:
-error_report("Error: HV_NO_RESOURCES");
-break;
-case HV_NO_DEVICE:
-error_report("Error: HV_NO_DEVICE");
-break;
-case HV_UNSUPPORTED:
-error_report("Error: HV_UNSUPPORTED");
-break;
+case HV_SUCCESS:  return "HV_SUCCESS";
+case HV_ERROR:return "HV_ERROR";
+case HV_BUSY: return "HV_BUSY";
+case HV_BAD_ARGUMENT: return "HV_BAD_ARGUMENT";
+case HV_NO_RESOURCES: return "HV_NO_RESOURCES";
+case HV_NO_DEVICE:return "HV_NO_DEVICE";
+case HV_UNSUPPORTED:  return "HV_UNSUPPORTED";
 #if defined(MAC_OS_VERSION_11_0) && \
 MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_VERSION_11_0
-case HV_DENIED:
-error_report("Error: HV_DENIED");
-break;
+case HV_DENIED:   return "HV_DENIED";
 #endif
-default:
-error_report("Unknown Error");
+default:  return "[unknown hv_return value]";
 }
+}
+
+void assert_hvf_ok_impl(hv_return_t ret, const char *file, unsigned int line,
+const char *exp)
+{
+if (ret == HV_SUCCESS) {
+return;
+}
+
+error_report("Error: %s = %s (0x%x, at %s:%u)",
+exp, hvf_return_string(ret), ret, file, line);
 
 abort();
 }
diff --git a/include/sysemu/hvf_int.h b/include/sysemu/hvf_int.h
index 30e739a2b5..5b28d17ba1 100644
--- a/include/sysemu/hvf_int.h
+++ b/include/sysemu/hvf_int.h
@@ -60,7 +60,10 @@ struct AccelCPUState {
 bool dirty;
 };
 
-void assert_hvf_ok(hv_return_t ret);
+void assert_hvf_ok_impl(hv_return_t ret, const char *file, unsigned int line,
+const char *exp);
+#define assert_hvf_ok(EX) assert_hvf_ok_impl((EX), __FILE__, __LINE__, #EX)
+const char *hvf_return_string(hv_return_t ret);
 int hvf_arch_init(void);
 int hvf_arch_init_vcpu(CPUState *cpu);
 void hvf_arch_vcpu_destroy(CPUState *cpu);
-- 
2.36.1

[PATCH v3 6/7] i386/hvf: Updates API usage to use modern vCPU run function

[Phil Dennis-Jordan]

macOS 10.15 introduced the more efficient hv_vcpu_run_until() function
to supersede hv_vcpu_run(). According to the documentation, there is no
longer any reason to use the latter on modern host OS versions, especially
after 11.0 added support for an indefinite deadline.

Observed behaviour of the newer function is that as documented, it exits
much less frequently - and most of the original function’s exits seem to
have been effectively pointless.

Another reason to use the new function is that it is a prerequisite for
using newer features such as in-kernel APIC support. (Not covered by
this patch.)

This change implements the upgrade by selecting one of three code paths
at compile time: two static code paths for the new and old functions
respectively, when building for targets where the new function is either
not available, or where the built executable won’t run on older
platforms lacking the new function anyway. The third code path selects
dynamically based on runtime detected availability of the weakly-linked
symbol.

Signed-off-by: Phil Dennis-Jordan 
---
 target/i386/hvf/hvf.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index 106ac5cbf6..2d0eef6cd9 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -427,6 +427,27 @@ static void hvf_cpu_x86_cpuid(CPUX86State *env, uint32_t 
index, uint32_t count,
 }
 }
 
+static hv_return_t hvf_vcpu_run(hv_vcpuid_t vcpu_id)
+{
+/*
+ * hv_vcpu_run_until is available and recommended from macOS 10.15+,
+ * HV_DEADLINE_FOREVER from 11.0. Test for availability at runtime and fall
+ * back to hv_vcpu_run() only where necessary.
+ */
+#ifndef MAC_OS_VERSION_11_0
+return hv_vcpu_run(vcpu_id);
+#elif MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_VERSION_11_0
+return hv_vcpu_run_until(vcpu_id, HV_DEADLINE_FOREVER);
+#else /* MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_VERSION_11_0 */
+/* 11.0 SDK or newer, but could be < 11 at runtime */
+if (__builtin_available(macOS 11.0, *)) {
+return hv_vcpu_run_until(vcpu_id, HV_DEADLINE_FOREVER);
+} else {
+return hv_vcpu_run(vcpu_id);
+}
+#endif
+}
+
 int hvf_vcpu_exec(CPUState *cpu)
 {
 X86CPU *x86_cpu = X86_CPU(cpu);
@@ -455,7 +476,7 @@ int hvf_vcpu_exec(CPUState *cpu)
 return EXCP_HLT;
 }
 
-hv_return_t r  = hv_vcpu_run(cpu->accel->fd);
+hv_return_t r = hvf_vcpu_run(cpu->accel->fd);
 assert_hvf_ok(r);
 
 /* handle VMEXIT */
-- 
2.36.1

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

On 03/06/2024 17:25, D. J. Bernstein wrote:

I'm still puzzled as to what led to the statement that I quoted at the 
beginning:

P 256 is the most popular curve in the world besides the bitcoin
curve. And I don’t have head to head numbers, and the bitcoin curve
is SEC P, but P 256 is most popular curve on the internet. So
certificates, TLS, handshakes, all of that is like 70 plus percent
negotiated with the P 256 curve.

Maybe the TLS co-chair has a comment?


On 03/06/2024 22:19, D. J. Bernstein wrote:

As I said, the statement is from one of the current TLS co-chairs, a
month before the co-chair appointment. The position as co-chair adds to
the importance of ensuring accurate information.


Dan, this is unsavory conduct. We are here to have reasoned, impersonal 
discussions. Please see in particular the second guideline for conduct 
at the IETF (RFC 7154).


Trying to call out an individual for a comment made informally, in some 
other corner of the internet, some time ago, is rather unbecoming of you 
and looks as though you're trying to use the working group's time and 
energy to settle a playground squabble. Especially when the referenced 
comment was unconnected to any active discussion within the WG or 
decisions made by the chairs.


Your thread has raised two technical & impersonal questions relevant to 
the TLS WG. Let's keep the focus on them:


1) What cryptographic algorithms are popularly used with TLS today?

2) Does this popularity matter for deciding which PQ hybrids to 
standardize in TLS?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

On 02/06/2024 22:02, Filippo Valsorda wrote:

Third, we learned to make key shares always ephemeral which makes 
invalid curve attacks irrelevant.


Although using ephemeral keys does effectively prevent key recovery 
through invalid points, you can still use invalid points to perform 
confinement attacks on an otherwise prime order curve.


This was used by Eli Biham and Lior Neumann to break Bluetooth pairing 
standard back in 2018 [1]. The Bluetooth standard previously said 
implementers could choose to do full point validation or always use 
ephemeral keys, and folks opted for the less complex choice. This isn't 
a clear separator between X25519 and P-256 though, since X25519 would 
also need to reject small order points in order to avoid the same attack.


Best,
Dennis

[1] 
https://biham.cs.technion.ac.il/BT/bt-fixed-coordinate-invalid-curve-attack.pdf 



(Also summarized in 7.2 of Prime Order Please 
https://eprint.iacr.org/2019/526.pdf)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Results for 14.1.0 (GENUNIX Sun Jun 2 19:47:18 UTC 2024) testsuite on powerpc64le-unknown-linux-gnu

[Dennis Clarke via Gcc-testresults]

0 
(GENUNIX Sun Jun  2 19:47:18 UTC 2024)


=== g++ tests ===


Running target unix

=== g++ Summary ===

# of expected passes259801
# of expected failures  2623
# of unsupported tests  11688
/opt/bw/build/gcc-14.1.0_ppc64le_debian.002/gcc/xg++  version 14.1.0 
(GENUNIX Sun Jun  2 19:47:18 UTC 2024)


=== gnat tests ===


Running target unix

=== gnat Summary ===

# of expected passes3458
# of expected failures  24
# of unsupported tests  26
/opt/bw/build/gcc-14.1.0_ppc64le_debian.002/gcc/gnatmake version 14.1.0

=== go tests ===


Running target unix

=== go Summary ===

# of expected passes8889
# of untested testcases 7
# of unsupported tests  32
/opt/bw/build/gcc-14.1.0_ppc64le_debian.002/gcc/gccgo  version 14.1.0 
(GENUNIX Sun Jun  2 19:47:18 UTC 2024)


=== obj-c++ tests ===


Running target unix

=== obj-c++ Summary ===

# of expected passes1503
# of expected failures  10
# of unsupported tests  79
/opt/bw/build/gcc-14.1.0_ppc64le_debian.002/gcc/xg++  version 14.1.0 
(GENUNIX Sun Jun  2 19:47:18 UTC 2024)


=== objc tests ===


Running target unix

=== objc Summary ===

# of expected passes2846
# of unsupported tests  70
/opt/bw/build/gcc-14.1.0_ppc64le_debian.002/gcc/xgcc  version 14.1.0 
(GENUNIX Sun Jun  2 19:47:18 UTC 2024)


=== gotools tests ===


=== gotools Summary ===
# of expected passes415
# of untested testcases 130
/opt/bw/build/gcc-14.1.0_ppc64le_debian.002/./gcc/gccgo version 14.1.0 
(GENUNIX Sun Jun 2 19:47:18 UTC 2024)


=== libatomic tests ===


Running target unix

=== libatomic Summary ===

# of expected passes54
=== libffi tests ===


Running target unix

=== libffi Summary ===

# of expected passes1462
# of unsupported tests  28
=== libgo tests ===


Running target unix

=== libgo Summary ===

# of expected passes196
/opt/bw/build/gcc-14.1.0_ppc64le_debian.002/./gcc/gccgo version 14.1.0 
(GENUNIX Sun Jun 2 19:47:18 UTC 2024)


=== libgomp tests ===


Running target unix
WARNING: libgomp.fortran/nestedfn5.f90   -O1  execution test program 
timed out.

FAIL: libgomp.fortran/nestedfn5.f90   -O1  execution test
WARNING: libgomp.fortran/nestedfn5.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test 
program timed out.
FAIL: libgomp.fortran/nestedfn5.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
WARNING: libgomp.fortran/nestedfn5.f90   -O3 -g  execution test program 
timed out.

FAIL: libgomp.fortran/nestedfn5.f90   -O3 -g  execution test
WARNING: libgomp.fortran/task-detach-10.f90   -O1  execution test 
program timed out.

FAIL: libgomp.fortran/task-detach-10.f90   -O1  execution test
WARNING: libgomp.fortran/task-detach-10.f90   -O2  execution test 
program timed out.

FAIL: libgomp.fortran/task-detach-10.f90   -O2  execution test
WARNING: libgomp.fortran/task-detach-8.f90   -O0  execution test program 
timed out.

FAIL: libgomp.fortran/task-detach-8.f90   -O0  execution test
WARNING: libgomp.fortran/task-detach-8.f90   -O2  execution test program 
timed out.

FAIL: libgomp.fortran/task-detach-8.f90   -O2  execution test

=== libgomp Summary ===

# of expected passes16150
# of unexpected failures7
# of expected failures  285
# of unsupported tests  699
=== libitm tests ===


Running target unix

=== libitm Summary ===

# of expected passes44
# of expected failures  3
# of unsupported tests  1
=== libstdc++ tests ===


Running target unix

=== libstdc++ Summary ===

# of expected passes18546
# of expected failures  126
# of unsupported tests  744

Compiler version: 14.1.0 (GENUNIX Sun Jun 2 19:47:18 UTC 2024)
Platform: powerpc64le-unknown-linux-gnu
configure flags: --prefix=/opt/bw/gcc14
--with-gnu-as --with-as=/opt/bw/imed/bin/gas
--with-gnu-ld --with-ld=/opt/bw/imed/bin/gld
--disable-nls --enable-threads=posix --enable-shared
--with-build-time-tools=/opt/bw/imed/bin --with-cpu=power9
--enable-bootstrap --enable-stage1-languages=c,c++
--enable-checking=misc --enable-stage1-checking=misc
--enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++
--with-pkgversion='GENUNIX Sun Jun  2 19:47:18 UTC 2024'
EOF


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

[marxmail] Britain’s century long Opium trafficking and China’s century of humiliation (1839-1949)

[Dennis Brasky]

In 1500, India and China were the world’s most advanced civilizations. Then
came the Europeans. They eventually looted and wreaked havoc on both, just
as they were to on the Americas and Africa. For India and China, Britain
was the chief culprit, relying on state-sponsored drug-running backed by
industrialized military power. The British Empire was the world’s largest
producer and exporter of Opium—the main product of global trade after the
gradual decline of the slave trade from Africa. Their “civilization”
brought the Century of Humiliation to China, which only ended with the
popular revolution led by Mao Zedong. This historic trauma and the struggle
to overcome it and re-establish their country is etched in the minds of the
Chinese today.

https://mronline.org/2024/05/30/britains-century-long-opium-trafficking-and-chinas-century-of-humiliation-1839-1949/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30609): https://groups.io/g/marxmail/message/30609
Mute This Topic: https://groups.io/mt/106461711/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [FFmpeg-devel] [PATCH] movenc: Add an option for hiding fragments at the end

[Dennis Sädtler via ffmpeg-devel]

On 2024-06-03 09:51, Martin Storsjö wrote:
Finally, I've also had a somewhat cursed thought about having a 
second always-hidden ftyp before the initial moov, which would then 
allow you to use the same file for progressive download and DASH/HLS 
streaming by using range-requests (e.g. via BYTERANGE) to skip the 
first ftyp + mdat header for the init segment and then using the 
fragments as normal. Though that goes beyond the scope of this patch, 
I just had to get it out there in case anybody thinks that might 
actually be fun to try :P


Oh, that sounds quite cursed indeed. I definitely can see the appeal 
of it :-) I guess it'd require some custom tooling to parse out the 
relevant byte ranges from it though (or maybe just listening to the 
avio marker callbacks?).


It would at least require the DASH/HLS manifest creation tooling to 
understand this hack and skip the first N bytes. As I said this is kind 
of a fun idea but maybe not entirely practical.


Anyway, Timo had thoughts about the name for this option/flag - do you 
have any suggestions to follow up with on that thread?


Not really, I think "hide_fragments" is fine. Though perhaps the flag's 
description could explain what it does in a bit more detail.


For OBS I settled on "Hybrid MP4" and calling the process of hiding the 
fragments a "soft remux", but the name of the flag should probably be a 
bit more technical.


~Dennis

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: 29 failed tests in the Texinfo 7.1 testsuite on Debian with IBM POWER9

[Dennis Clarke via Bug reports for the GNU Texinfo documentation system]

On 6/1/24 05:55, Patrice Dumas wrote:

On Sat, Jun 01, 2024 at 01:17:59AM -0400, Dennis Clarke via Bug reports for the 
GNU Texinfo documentation system wrote:


FAIL: test_scripts/nested_formats_texi_nested_formats.sh

Why fail? I have no idea.

This is Debian on an IBM POWER9 server :


Maybe something to do with specifics of POWER9, I guess it could be
somewhat peculiar.  Also the gcc seems very recent to me, could also be
that.

Could you please send the log file of any of these failed tests, for
example

tp/tests/nested_formats/test_log/texi_nested_formats.log


dax$ gcc --version
gcc (GENUNIX Thu May 30 01:20:34 UTC 2024) 14.1.0





The patch works !


dax$
dax$ grep -E '^\=\=\=|^Test|^\#' 
../texinfo-7.1_ppc64le_debian.003.check.log


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 87
# PASS:  87
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 59
# PASS:  59
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 0
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 110
# PASS:  73
# SKIP:  37
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 9
# PASS:  5
# SKIP:  4
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0


Testsuite summary for GNU Texinfo 7.1

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

dax$


Does no one test anything anymore on stuff other than RHEL on x86_64?

[ rant ]
I am willing to bet the RHEL on POWER10 stuff works flawlessly but no
one posts the changes back upstream.
[ end rant ]

Just as soon as I have a POWER10 in my life you can bet I will be doing
testing and work and getting that monster to serve open source goodness!


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: [FFmpeg-devel] [PATCH] movenc: Add an option for hiding fragments at the end

[Dennis Sädtler via ffmpeg-devel]

On 2024-06-02 21:36, Martin Storsjö wrote:

On Sat, 1 Jun 2024, Dennis Sädtler via ffmpeg-devel wrote:

Should the ftyp atom also be updated to remove brands no longer 
required for non-fragmented files?
I'm not sure how important that is in real-world scenarios, so it 
might not be worth it to deal with some of the additional changes 
required e.g. to deal with the new ftyp possibly being a different size.


Hmm, good point, I hadn't thought about that. I'd prefer not to do 
that, as it becomes a bit more of a mess to change the size of the ftyp.


Indeed, though as far as I can tell only the offset and size of the mdat 
would need to be changed, since everything past the ftyp is "disposable" 
anyway.
But as I initially mentioned, I have no idea if there are real-word 
cases of players refusing a file purely based on those brands.


Since coincidentally I've implemented the exact same feature in a 
different application a couple weeks ago I'll also throw in the fun 
fact that files produced this way can be smaller than regular MP4s 
for long and/or large files.
This is due to the lack of interleaving of A/V samples resulting in 
the file having much fewer but larger chunks, which means the moov 
atom - mainly the stco/co64 and stsc boxes - can be much smaller.


Oh, indeed, that's a good point. But on the other hand, the file ends 
up containing all the leftover moof boxes in the mdat. But are you 
saying that a compact moov + leftover moof, still is smaller than one 
large moov, in your practical test cases?


Yep, that's what I meant! The initial ("empty") moov and following moof 
boxes aren't all that big, so once you go over a certain threshold 
(which I haven't calculated) this method ends up having a negative overhead.


I have a regular MP4 of a Twitch live stream (1 video + 1 audio track) 
where the moov alone ends up being ~40 MiB, so they can get quite large. 
That may be part of why the newer ISO-BMFF revisions actually have a 
feature for compressing moov/moof/sidx boxes (that nobody has 
implemented as far as I can tell).


Btw, the patch in this form has one minimal time gap for when the file 
can end up unrecoverable; we patch the mdat size (hiding the moof 
boxes) before we write the moov - if we die at that specific moment, 
we'd have an unreadable file. I guess it should be possible to reorder 
these two calls as well - but it makes for a slightly bigger patch.


First writing the moov and then hiding the fragmentation is what I ended 
up doing in my implementation. Might be overkill, but would certainly 
make it the "safest" it can be.


In my implementation I also ended up changing the placeholder "free" 
atom at the start to be 16 bytes so that I could write the mdat header 
non-destructively and allow the fragmented structure to be preserved 
entirely. This was mostly done for easier manual recovery in case 
something goes wrong with the full moov, though again, probably overkill.


Finally, I've also had a somewhat cursed thought about having a second 
always-hidden ftyp before the initial moov, which would then allow you 
to use the same file for progressive download and DASH/HLS streaming by 
using range-requests (e.g. via BYTERANGE) to skip the first ftyp + mdat 
header for the init segment and then using the fragments as normal. 
Though that goes beyond the scope of this patch, I just had to get it 
out there in case anybody thinks that might actually be fun to try :P


~Dennis

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: 29 failed tests in the Texinfo 7.1 testsuite on Debian with IBM POWER9

[Dennis Clarke via Bug reports for the GNU Texinfo documentation system]

On 6/1/24 05:55, Patrice Dumas wrote:

On Sat, Jun 01, 2024 at 01:17:59AM -0400, Dennis Clarke via Bug reports for the 
GNU Texinfo documentation system wrote:


FAIL: test_scripts/nested_formats_texi_nested_formats.sh

Why fail? I have no idea.

This is Debian on an IBM POWER9 server :


Maybe something to do with specifics of POWER9, I guess it could be
somewhat peculiar.  Also the gcc seems very recent to me, could also be
that.


I was baffled. I also did the exact same tests on a bog standard off
the shelf boring Xeon machine and everything works like a charm with the
same GCC release :

oberon$ uname -a
Linux oberon 6.6.26-genunix #1 SMP Thu Apr 11 13:57:18 GMT 2024 x86_64 
GNU/Linux

oberon$ gcc --version
gcc (GENUNIX Wed May 29 23:34:00 UTC 2024) 14.1.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

oberon$
oberon$
oberon$ as --version
GNU assembler (GNU Binutils) 2.42
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-pc-linux-gnu'.
oberon$

So .. that explains the "wow" email I just had to send in! :)



Could you please send the log file of any of these failed tests, for
example


Yes indeed !




tp/tests/nested_formats/test_log/texi_nested_formats.log


dax$ gcc --version
gcc (GENUNIX Thu May 30 01:20:34 UTC 2024) 14.1.0




I could isolate just the failed tests but may as well tarball up
the entire pile?  For now .. just the failed tests. I have attached
a GNU tar file ( xz compressed ) of the logs and have also jsut run
at least "nested_formats_texi_nested_formats.sh" which spits out a
massive pile of diff lines :

dax$
dax$ uname -a
Linux dax 6.1.86-mrw1 #1 SMP Sat Apr 13 20:47:03 PDT 2024 ppc64le GNU/Linux
dax$
dax$ echo $SHELL
/bin/bash
dax$
dax$ env | grep '^L'
LOGNAME=dclarke
LESS_IS_MORE=1
LANG=en_US.UTF-8
LD=/opt/bw/bin/gld
LC_TIME=C
dax$
dax$ ./tp/tests/test_scripts/nested_formats_texi_nested_formats.sh ^C
dax$ cd ./tp/tests/
dax$
dax$ test_scripts/nested_formats_texi_nested_formats.sh
D: nested_formats//diffs/texi_nested_formats_html.diff (printed below)
diff -a -u -r 
./nested_formats//res_parser_html/texi_nested_formats/index.html 
nested_formats//out_parser_html/texi_nested_formats/index.html
--- ./nested_formats//res_parser_html/texi_nested_formats/index.html 
2023-10-17 12:13:33.0 +
+++ nested_formats//out_parser_html/texi_nested_formats/index.html 
2024-06-02 00:14:01.079764772 +

@@ -93,10 +93,10 @@
 

 
-multitable headitemwidth="70%">another tab
-multitable itemwidth="70%">multitable tab
-multitable item 2width="70%">multitable tab 2

-lone multitable item
+multitable headitemwidth="70%">another tab
+multitable itemwidth="70%">multitable tab
+multitable item 2width="70%">multitable tab 2

+lone multitable item
 
 

.
.
.
endless pile of similar diffs.


@@ -3667,10 +3667,10 @@
 

 
-multitable headitemwidth="70%">another tab
-multitable itemwidth="70%">multitable tab
-multitable item 2width="70%">multitable tab 2

-lone multitable item
+multitable headitemwidth="70%">another tab
+multitable itemwidth="70%">multitable tab
+multitable item 2width="70%">multitable tab 2

+lone multitable item
 
 

D: nested_formats//diffs/texi_nested_formats_html.diff (printed above)
testdir: nested_formats/
driving_file: ./nested_formats//list-of-tests
found special first line, commands now: : :_html
made result dir: ./nested_formats//res_parser/
made result dir: ./nested_formats//res_parser_html/

doing test texi_nested_formats, src_file 
./nested_formats//nested_formats.texi

format_option:
texi2any.pl texi_nested_formats -> 
nested_formats//out_parser/texi_nested_formats
 /opt/bw/bin/perl -w ./..//texi2any.pl  --force --conf-dir ./../t/init/ 
--conf-dir ./../init --conf-dir ./../ext -I ./nested_formats/ -I 
nested_formats// -I ./ -I . -I built_input --error-limit=1000 -c TEST=1 
--output nested_formats//out_parser/texi_nested_formats/ -c 
TEXINFO_OUTPUT_FORMAT=plaintexinfo ./nested_formats//nested_formats.texi 
> nested_formats//out_parser/texi_nested_formats/nested_formats.1 
2>nested_formats//out_parser/texi_nested_formats/nested_formats.2


doing test texi_nested_formats, src_file 
./nested_formats//nested_formats.texi

format_option: --html
texi2any.pl texi_nested_formats -> 
nested_formats//out_parser_html/texi_nested_formats
 /opt/bw/bin/perl -w ./..//texi2any.pl --html --force --conf-dir 
./../t/init/ --conf-dir ./../init --conf-dir ./../ext -I 
./nested_formats/ -I nested_formats// -I ./ -I . -I built_input 

[marxmail] Can Palestinians imagine a future with Israelis after this war?

[Dennis Brasky]

My grandfather remembers neighborly relations with Jews before 1948. For
Palestinians today, such a prospect seems nearly impossible.
https://www.972mag.com/israeli-palestinian-reconciliation-post-gaza/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30581): https://groups.io/g/marxmail/message/30581
Mute This Topic: https://groups.io/mt/106432872/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[MARMAM] SMM2024 Workshop - Entanglement of Large Whales in Trap/Pot Gear

[Dennis Heinemann]

Dear MARMAM Community,

We would like to announce that we will be hosting a workshop on the 
entanglement of large whales in trap/pot gear at the biennial conference, which 
is being held this November in Perth, Australia.  If you are interested, then 
please read on and let us know of your plans - see questions at end.

The full-day workshop will take place before the conference on Sunday, November 
10th at the conference venue (Perth Convention and Exhibition Centre).

The purpose of the workshop is to bring together a range of stakeholders from 
around the world to share their knowledge and experience with a range of topics 
associated with the entanglement of large whales in the fishing gear used by 
pot/trap fisheries. In addition, we welcome the participation of newcomers to 
this issue who are looking to learn from the experiences of others.  We hope 
that the workshop will catalyze the creation of a network of individuals who 
will continue to share their knowledge and experiences, leading to an improved 
understanding and mitigation of entanglement of large whales in trap/pot gear.  
The workshop will likely include a few presentations, a lot of discussion, and 
some planning of additional actions aimed at connecting people.  At this time, 
there are not any plans to make the workshop available online; in other words 
participation will be in-person only.

Please let Dennis know if are interested in attending, what experience you 
would bring, what topics you would want to discuss, and what you might want to 
get out of the workshop.

Thanks for your attention,

  Dennis Heinemann, PhD
  Senior Advisor - Fisheries
  U.S. Marine Mammal Commission
  Bethesda, Maryland USA
  dheinem...@mmc.gov<mailto:dheinem...@mmc.gov>
  +1 202.436.1467

  Julia O'Hern, PhD
  Associate Director Entanglement Response and Prevention
  The Marine Mammal Center
  Moss Landing, California USA
   ohe...@tmmc.org<mailto:ohe...@tmmc.org>
  +1 831.708.5858


___
MARMAM mailing list
MARMAM@lists.uvic.ca
https://lists.uvic.ca/mailman/listinfo/marmam

Re: [FFmpeg-devel] [PATCH] movenc: Add an option for hiding fragments at the end

[Dennis Sädtler via ffmpeg-devel]

On 2024-05-31 10:53, Martin Storsjö wrote:

This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
This is, incidentally, how Apple devices do (or at least did, at some
point) their writing of files when recording, at least with some
of their userspace APIs.
---
Should the ftyp atom also be updated to remove brands no longer required 
for non-fragmented files?
I'm not sure how important that is in real-world scenarios, so it might 
not be worth it to deal with some of the additional changes required 
e.g. to deal with the new ftyp possibly being a different size.


Since coincidentally I've implemented the exact same feature in a 
different application a couple weeks ago I'll also throw in the fun fact 
that files produced this way can be smaller than regular MP4s for long 
and/or large files.
This is due to the lack of interleaving of A/V samples resulting in the 
file having much fewer but larger chunks, which means the moov atom - 
mainly the stco/co64 and stsc boxes - can be much smaller.


Also good to know that Apple thought of this as well. I had no idea 
about that, but that further justifies adopting this method for 
achieving resilient but compatible recordings in my mind.


~ Dennis
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

29 failed tests in the Texinfo 7.1 testsuite on Debian with IBM POWER9

[Dennis Clarke via Bug reports for the GNU Texinfo documentation system]

I have no idea what this is such a terrible result :



Testsuite summary for GNU Texinfo 7.1

# TOTAL: 110
# PASS:  44
# SKIP:  37
# XFAIL: 0
# FAIL:  29
# XPASS: 0
# ERROR: 0



That is just unusable.

A whole bucket of strange scripts fail :

FAIL: test_scripts/nested_formats_texi_nested_formats.sh
FAIL: test_scripts/nested_formats_nested_group.sh
FAIL: test_scripts/nested_formats_nested_itemize.sh
FAIL: test_scripts/nested_formats_nested_menu.sh
FAIL: test_scripts/nested_formats_nested_table.sh
FAIL: test_scripts/nested_formats_nested_flushright.sh
FAIL: test_scripts/nested_formats_nested_multitable.sh
FAIL: test_scripts/nested_formats_nested_cartouche.sh
FAIL: test_scripts/nested_formats_nested_enumerate.sh
FAIL: test_scripts/nested_formats_nested_deffn.sh
FAIL: test_scripts/nested_formats_nested_example.sh
FAIL: test_scripts/nested_formats_nested_quotation.sh
FAIL: test_scripts/coverage_formatting_html_no_split.sh
FAIL: test_scripts/coverage_formatting_epub.sh
FAIL: test_scripts/coverage_formatting_xhtml.sh
FAIL: test_scripts/coverage_formatting_chm.sh
FAIL: test_scripts/coverage_formatting_regions.sh
FAIL: test_scripts/layout_formatting_texi2html.sh
FAIL: test_scripts/layout_formatting_texi2html_nodes.sh
FAIL: test_scripts/layout_formatting_sort_element_counts.sh
FAIL: test_scripts/layout_formatting_mathjax.sh
FAIL: test_scripts/layout_formatting_weird_quotes.sh
FAIL: test_scripts/layout_formatting_numerical_entities.sh
FAIL: test_scripts/layout_formatting_enable_encoding.sh
FAIL: test_scripts/layout_formatting_exotic.sh
FAIL: test_scripts/layout_formatting_inline_css.sh
FAIL: test_scripts/layout_formatting_fr.sh
FAIL: test_scripts/layout_formatting_fr_icons.sh
FAIL: test_scripts/layout_formatting_epub_nodes.sh

Looking at the first script :

dax$
dax$ cat ./tp/tests/test_scripts/nested_formats_texi_nested_formats.sh
#! /bin/sh
# This file generated by maintain/regenerate_cmd_tests.sh

if test z"$srcdir" = "z"; then
  srcdir=.
fi

one_test_logs_dir=test_log


dir=nested_formats
name='texi_nested_formats'
mkdir -p $dir

"$srcdir"/run_parser_all.sh -dir $dir $name
exit_status=$?
cat $dir/$one_test_logs_dir/$name.log
exit $exit_status

dax$

Why fail? I have no idea.

This is Debian on an IBM POWER9 server :

dax$ cat /etc/debian_version
12.5
dax$
dax$ uname -a
Linux dax 6.1.86-mrw1 #1 SMP Sat Apr 13 20:47:03 PDT 2024 ppc64le GNU/Linux
dax$

With pretty recent tools :

dax$
dax$ gcc --version
gcc (GENUNIX Thu May 30 01:20:34 UTC 2024) 14.1.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dax$
dax$ gas --version
GNU assembler (GNU Binutils) 2.40
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of 
`powerpc64le-unknown-linux-gnu'.

dax$

Any insights ?



--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Results for 14.1.0 (GENUNIX Thu May 30 01:20:34 UTC 2024) testsuite on powerpc64le-unknown-linux-gnu

[Dennis Clarke via Gcc-testresults]

0 
(GENUNIX Thu May 30 01:20:34 UTC 2024)


=== g++ tests ===


Running target unix

=== g++ Summary ===

# of expected passes259801
# of expected failures  2623
# of unsupported tests  11688
/opt/bw/build/gcc-14.1.0_ppc64le_debian.001/gcc/xg++  version 14.1.0 
(GENUNIX Thu May 30 01:20:34 UTC 2024)


=== gnat tests ===


Running target unix

=== gnat Summary ===

# of expected passes3458
# of expected failures  24
# of unsupported tests  26
/opt/bw/build/gcc-14.1.0_ppc64le_debian.001/gcc/gnatmake version 14.1.0

=== obj-c++ tests ===


Running target unix

=== obj-c++ Summary ===

# of expected passes1503
# of expected failures  10
# of unsupported tests  79
/opt/bw/build/gcc-14.1.0_ppc64le_debian.001/gcc/xg++  version 14.1.0 
(GENUNIX Thu May 30 01:20:34 UTC 2024)


=== objc tests ===


Running target unix

=== objc Summary ===

# of expected passes2846
# of unsupported tests  70
/opt/bw/build/gcc-14.1.0_ppc64le_debian.001/gcc/xgcc  version 14.1.0 
(GENUNIX Thu May 30 01:20:34 UTC 2024)


=== libatomic tests ===


Running target unix

=== libatomic Summary ===

# of expected passes54
=== libgomp tests ===


Running target unix
WARNING: libgomp.fortran/target-imperfect2.f90   -O0  execution test 
program timed out.

FAIL: libgomp.fortran/target-imperfect2.f90   -O0  execution test

=== libgomp Summary ===

# of expected passes16156
# of unexpected failures1
# of expected failures  285
# of unsupported tests  699
=== libitm tests ===


Running target unix

=== libitm Summary ===

# of expected passes44
# of expected failures  3
# of unsupported tests  1
=== libstdc++ tests ===


Running target unix

=== libstdc++ Summary ===

# of expected passes18546
# of expected failures  126
# of unsupported tests  744

Compiler version: 14.1.0 (GENUNIX Thu May 30 01:20:34 UTC 2024)
Platform: powerpc64le-unknown-linux-gnu
configure flags: --prefix=/opt/bw/imed/gcc14 --with-gnu-as
--with-as=/opt/bw/bin/gas --with-gnu-ld --with-ld=/opt/bw/bin/gld
--disable-nls --enable-threads=posix --enable-shared
--with-build-time-tools=/opt/bw/bin --with-cpu=power9 --enable-bootstrap
--enable-stage1-languages=c,c++ --enable-checking=misc
--enable-stage1-checking=misc
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++
--with-pkgversion='GENUNIX Thu May 30 01:20:34 UTC 2024'
EOF




--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Results for 14.1.0 (GENUNIX Wed May 29 23:34:00 UTC 2024) testsuite on x86_64-pc-linux-gnu

[Dennis Clarke via Gcc-testresults]

/as --with-ld=/opt/bw/bin/ld
--with-pkgversion='GENUNIX Wed May 29 23:34:00 UTC 2024'
EOF

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

[marxmail] Palestinians Returning to Jabaliya in Northern Gaza Find Wide Devastation

[Dennis Brasky]

“The destruction is indescribable,” said Mohammad Awais, who returned with
his family to their home on Friday.
https://www.nytimes.com/2024/05/31/world/middleeast/israel-jabaliya-gaza-palestinians.html


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30565): https://groups.io/g/marxmail/message/30565
Mute This Topic: https://groups.io/mt/106416847/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Hundreds of Palestinian Doctors Disappeared Into Israeli Detention

[Dennis Brasky]

Khaled Al Serr, a young surgeon, vanished from Nasser Hospital in Khan
Younis two months ago. He hasn’t been heard from since.

https://theintercept.com/2024/05/24/gaza-palestinian-doctors-hospital-detained-missing-disappeared/


https://www.counterpunch.org/2024/05/31/who-by-fire-the-burning-of-rafah/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30563): https://groups.io/g/marxmail/message/30563
Mute This Topic: https://groups.io/mt/106409590/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] The Attack on the USS Liberty Symbolizes Israel’s Duplicity and Deceit

[Dennis Brasky]

“The State of Israel will be judged not by its wealth, nor by its army, nor
by its technology, but by its moral character and its human values.”

– Prime Minister David Ben-Gurion, 1955, Israel’s first prime minister and
defense minister.

Fifty-seven years ago during the Six-Day War (June 8, 1967), Israeli
Defense Forces (IDF) brutally attacked a U.S. naval intelligence ship that
was seconded to the National Security Agency (NSA) for intercepting
communications in the Middle East.  Thirty-four American sailors were
killed in the attack, and 171 were wounded by unmarked Mirage fighter
aircraft using cannons and rockets.  Israeli boats fired machine guns at
close range at those helping the wounded, including a Soviet naval vessel
that was trying to rescue U.S. sailors; they also machine-gunned life rafts
that survivors had dropped in hopes of abandoning the ship.  The Israelis
immediately called the disaster a “random accident.” It wasn’t “random” and
it wasn’t an “accident,” but the NSA investigation of the assault remains
classified to this day.

https://www.counterpunch.org/2024/05/31/the-attack-on-the-uss-liberty-symbolizes-israels-duplicity-and-deceit/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30561): https://groups.io/g/marxmail/message/30561
Mute This Topic: https://groups.io/mt/106409203/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Philippines found guilty of massive human rights violations

[Dennis Brasky]

a longtime US colony

https://www.counterpunch.org/2024/05/30/philippines-found-guilty-of-massive-human-right-violations/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30555): https://groups.io/g/marxmail/message/30555
Mute This Topic: https://groups.io/mt/106392151/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] NEXT THURSDAY: Corporate Colonialism & Indigenous Resistance in Latin America

[Dennis Brasky]

>
>
> We’re about to drop a bombshell report on the harm neocolonial trade deals
> have inflicted on Indigenous peoples across Latin America.
>
> *Join us **online*
> *
> for a very special report launch event on Thursday, June 6th from 2:00-5:00
> PM ET. *
>
> 
>  RSVP
> Here
> 
>  Thursday,
> June 6 | 2:00 PM - 5:00 PM ET
>
> Land stolen, water poisoned, communities destroyed – these are the
> consequences of corporate trade policy in Latin America.
>
> In particular, Investor-State Dispute Settlement (ISDS), a system embedded
> in many trade deals, empowers corporations to sue governments over public
> interest policies – and continues to punish and systematically exclude
> frontline communities.
>
> This system has dire implications for human rights, environmental
> protection, and corporate accountability efforts. Indigenous communities
> have borne the brunt of these neocolonial policies, and they’re leading the
> charge to change them.
>
> On Thursday, June 6th
> ,
> join Indigenous leaders, community advocates, and legal and policy experts
> from Ecuador, Honduras, and the U.S. to learn about the damages caused by
> ISDS across Latin America and how we are organizing to eliminate it from
> U.S. trade deals.
>
> *The event will feature**:*
>
>-
>
>Honduran Black-English, Afro-Indigenous community leaders *Luisa
>Connor *and *Venessa C**á**rdenas*
>-
>
>Ecuadorian defenders of human rights and the Amazon *Donald Moncayo*
>and Siekopai youth leader *Consuelo Piaguage*
>-
>
>Other experts from Public Citizen, the Center for International
>Environmental Law, Amazon Watch, and Columbia University
>-
>
>A screening of *The Tribunal, *a powerful short documentary produced
>by Columbia University’s Center on Sustainable Investment.
>
> *Please RSVP here as space is limited! *
> *Tick
> the box indicating you’d like to join virtually to receive Zoom details. *
>
> Feel welcome to join the event at any time between 2 and 5pm ET. A
> detailed schedule and additional information regarding specific panel
> discussions can be found here
> 

[marxmail] India and Israel - comrades in ethno-nationalism

[Dennis Brasky]

Zionism and Hindutva share ideological roots, and increasingly followers of
both are finding common ground in propping up the same American politicians.

https://mondoweiss.net/2024/05/comrades-in-ethnonationalism-why-the-israel-lobby-is-supporting-u-s-politicians-friendly-to-indias-far-right/



You Can’t Turn Back the Clock on Genocide
https://tomdispatch.com/you-cant-turn-back-the-clock-on-genocide/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30553): https://groups.io/g/marxmail/message/30553
Mute This Topic: https://groups.io/mt/106391831/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: New OpenSSL Releases

[Dennis Clarke via openssl-users]

On 5/30/24 03:03, Tomas Mraz wrote:

You can just test the HEAD commits in the respective branches (openssl-
3.0, openssl-3.1, openssl-3.2 and openssl-3.3) in git. The repository
will be frozen today afternoon so there should be no further changes
apart from eventual regression fixes and the release commits.



OKay, thank you. I guess today is a good day to test on a few oddball
system architectures. I suspect there are very very few people out there
running actual HPE Itanium hardware or big-endian IBM POWER and that
often raises a few bugs that slip under the radar.


--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: New OpenSSL Releases

[Dennis Clarke via openssl-users]

On 5/28/24 08:51, Tomas Mraz wrote:

The OpenSSL project team would like to announce the upcoming release of
OpenSSL versions 3.3.1, 3.2.2, 3.1.6 and 3.0.14.



Will there be any release candidate tarballs for testing on various
systems?  Perhaps there already exists some commit or "tag" ( whatever
you want to call it ) in git ?



--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

[marxmail] Elon Musk’s company town

[Dennis Brasky]

To some, Musk has given Brownsville, Texas, a reason for being, a future.
To others, he’s a colonizer, flirting with white nationalists online while
exploiting a predominantly brown work force

https://www.nytimes.com/2024/05/24/opinion/elon-musk-spacex-brownsville-texas.html


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30539): https://groups.io/g/marxmail/message/30539
Mute This Topic: https://groups.io/mt/106372154/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Surveillance and Interference: Israel’s Covert War on the ICC Exposed

[Dennis Brasky]

Top Israeli government and security officials have overseen a nine-year
surveillance operation targeting the ICC and Palestinian rights groups to
try and thwart a war crimes probe a joint investigation reveals

https://www.972mag.com/icc-israel-surveillance-investigation/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30532): https://groups.io/g/marxmail/message/30532
Mute This Topic: https://groups.io/mt/106354019/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Climate Change Added a Month’s Worth of Extra-Hot Days in Past Year

[Dennis Brasky]

https://www.nytimes.com/2024/05/28/climate/extreme-heat-worldwide.html


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30531): https://groups.io/g/marxmail/message/30531
Mute This Topic: https://groups.io/mt/106351732/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[TLS]Re: Transitioning to PQC Certificates & Trust Expressions

[Dennis Jackson]

Hi Ryan,

On 27/05/2024 19:23, Ryan Hurst wrote:
I don't understand your position on the verifier, the faith one can 
put in the chain of signatures is only the faith appropriate for the 
weakest signature. As such if a classical key is used to sign a PQ 
chain, an attacker would go after the classical signature ignoring the 
others.


That's not quite right.

Let's imagine we have a leaf public key L1, a PQ Public Key M1 and a 
Classical Public Key N1 and use <- to indicate 'signed by'. Consider the 
certificate chains:


    (1) L1 <- M1

    (2) N1 -> L1 <- M1  (N1 and M1 are both intermediates signing the 
same leaf)


    (3) L1 <- M1 <- N1 (N1 cross-signs M1).

Have we made things worse in (2) by adding a classical signature? No. 
Any verifier that would output accept on (1), will also output accept on 
(2) without even checking N1. So we cannot have made security worse for 
anyone that would accept (1). The opposite is also true, anyone that 
would trust N1 will not need to verify M1. So (2) strictly improves 
availability without reducing security for anyone. (This was my proposed 
design in the initial mail).


For (3), we still have the property that anyone that would output accept 
on (1) would output accept on (3) without checking N1, so security for 
PQ users has not been reduced at all. The reverse direction for whether 
we hurt classical users requires us to trust that M1 is at least as 
secure as N1 - otherwise we're hurting security for the folks that trust 
N1 but not M1. In the context where M1 is a PQ-Hybrid and N1 is 
classical and both are operated by the same CA, this is perfectly fine. 
(This was my alternate design in the initial mail).


The important nuance is this: we can *add* as many certificates / 
signatures as we like to the leaf node of a chain in order to improve 
availability without hurting security. We can also extend PQ chains with 
classical roots, without degrading the security of PQ users in any way.


As a further thought experiment. Imagine we had a fully PQ PKI setup and 
established, then some attacker used their quantum computer to break a 
classical root and start adding a classical signature to all our secure 
PQ chains. This action would not impact security for any client which 
only trusted PQ signatures. They simply don't care about the classical 
signature and the attacker can't produce any new chains. For clients 
which did trust the classical signing algorithm, they're doomed no 
matter what, because the attacker can just make valid chains of their 
choice.


Security all comes down to roots and signatures the verifiers accepts, 
not the chains we make :-).


Best,
Dennis




Ryan

On Mon, May 27, 2024 at 11:15 AM Dennis Jackson 
 wrote:


Hi Ryan,

I wonder if the IETF mail servers are having a bad day again. I
only see your reply to me, no other messages and currently the
archives are only showing my initial email [1] with no replies.

[1] https://mailarchive.ietf.org/arch/browse/tls/

On 27/05/2024 18:51, Ryan Hurst wrote:

However, doing so with a hybrid chain weakens the security of the
chain to the security properties of the certificate and keys
being used for the cross-signing.


I don't think there's any such thing as the security of the chain.
Only the security of the *verifier* of the chain. If they trust a
classical root, they can't do better than classical security. If
they trust only PQ roots, it doesn't matter how many extraneous
classical certs are in the chain if there's a valid PQ path from
leaf to a known PQ root or intermediate. In both cases, the having
a classical signature on a PQ root or intermediate doesn't change
security for anybody, it only improves availability.

    Best,
Dennis




On Mon, May 27, 2024 at 9:51 AM Dennis Jackson
 wrote:

Hi Ryan,

On 27/05/2024 16:39, Ryan Hurst wrote:


[...]

Moreover, there's the liability issue: a CA that cross-signs
another CA exposes its business to distrust based on the
practices of the CA it cross-signs.

[...]

As someone who has both provided said cross-signs and
received them I really don't see them as the silver bullet
others seem to in this thread.


This thread is purely talking about cross-signs between two
roots operated by the same CA, which is the case when an
existing CA with classical root is generating a new PQ root.

This is completely standard practice, as exemplified by Let's
Encrypt, DigiCert and Sectigo's pages describing their cross
signs between the roots they operate [1,2,3]. There are no
commercial relationships or sensitivities involved because
the same organization controls both the signing and the
cross-signed root.

I guess you assumed the alternative scenario where the roots
belong to

[TLS]Re: Transitioning to PQC Certificates & Trust Expressions

[Dennis Jackson]

Hi Ryan,

I wonder if the IETF mail servers are having a bad day again. I only see 
your reply to me, no other messages and currently the archives are only 
showing my initial email [1] with no replies.


[1] https://mailarchive.ietf.org/arch/browse/tls/

On 27/05/2024 18:51, Ryan Hurst wrote:
However, doing so with a hybrid chain weakens the security of the 
chain to the security properties of the certificate and keys being 
used for the cross-signing.


I don't think there's any such thing as the security of the chain. Only 
the security of the *verifier* of the chain. If they trust a classical 
root, they can't do better than classical security. If they trust only 
PQ roots, it doesn't matter how many extraneous classical certs are in 
the chain if there's a valid PQ path from leaf to a known PQ root or 
intermediate. In both cases, the having a classical signature on a PQ 
root or intermediate doesn't change security for anybody, it only 
improves availability.


Best,
Dennis




On Mon, May 27, 2024 at 9:51 AM Dennis Jackson 
 wrote:


Hi Ryan,

On 27/05/2024 16:39, Ryan Hurst wrote:


[...]

Moreover, there's the liability issue: a CA that cross-signs
another CA exposes its business to distrust based on the
practices of the CA it cross-signs.

[...]

As someone who has both provided said cross-signs and received
them I really don't see them as the silver bullet others seem to
in this thread.


This thread is purely talking about cross-signs between two roots
operated by the same CA, which is the case when an existing CA
with classical root is generating a new PQ root.

This is completely standard practice, as exemplified by Let's
Encrypt, DigiCert and Sectigo's pages describing their cross signs
between the roots they operate [1,2,3]. There are no commercial
relationships or sensitivities involved because the same
organization controls both the signing and the cross-signed root.

I guess you assumed the alternative scenario where the roots
belong to two different CAs. The standard terminology of referring
to both as a cross-sign is regrettably vague.

Best,
Dennis

[1] Let's Encrypt X2 is cross signed by Let's Encrypt X1
https://letsencrypt.org/certificates/

[2] Digicert G5 by the Digicert Global Root CA

https://knowledge.digicert.com/tutorials/install-the-digicert-g5-cross-signed-root-ca-certificate

[3] Sectigo UserTrust is cross signed by Sectigo AAA

https://support.sectigo.com/articles/Knowledge/Sectigo-Chain-Hierarchy-and-Intermediate-Roots



Ryan Hurst

On Mon, May 27, 2024 at 2:31 AM Dennis Jackson
 wrote:

One of the key use cases proposed for Trust Expressions is
enabling a speedy deployment of PQC Certificates. I agree
this is an important use case to address, but I think a
closer inspection of the existing deployment options shows
that Trust Expressions does not provide any improvement or
new functionality over existing, already widely deployed
solutions.

In particular, having each CA cross-sign their new PQC root
with their existing classical root. This does not require any
new functionalities or code changes in TLS clients or
servers, does not require coordination between CAs / Root
Programs / Clients and does not impose any performance impact
on the connection (perhaps surprisingly).

The rest of this message details the Trust Expressions
proposal for a PQC transition and compares the security and
performance to existing solutions.

*The Trust Expressions Proposal for the PQC Transition
*When we come to transition to PQC Certificates, the various
Root Programs will include various PQC Roots and start
distributing them to their clients. They will also configure
their clients to start advertising the relevant PQC / hybrid
signature algorithms in their signature_algorithms_cert TLS
Extensions. TLS Servers will decide whether to send their
classical chain or their PQC chain according to this extension.

The Trust Expressions authors plus quite a few folks on the
list have stated that this approach will require us to wait
for all major root programs to accept a given PQC Root and
then for that PQC root to be ubiquitously supported by all
clients which also advertise PQC Signature Support.
Otherwise, we might send our new PQ Chain to a client who
only has an older set of PQ Roots, which would cause a
connection failure. This wait could take a long time, even a
year or more.

Trust Expressions proposes that by having clients indicate
their trust store label and version, we can mostly skip
waiting for ubiquity. Through the Trust Expression's
negotiation, we can be sure

[TLS]Re: Transitioning to PQC Certificates & Trust Expressions

[Dennis Jackson]

Hi Ryan,

On 27/05/2024 16:39, Ryan Hurst wrote:


[...]

Moreover, there's the liability issue: a CA that cross-signs another 
CA exposes its business to distrust based on the practices of the CA 
it cross-signs.


[...]

As someone who has both provided said cross-signs and received them I 
really don't see them as the silver bullet others seem to in this thread.


This thread is purely talking about cross-signs between two roots 
operated by the same CA, which is the case when an existing CA with 
classical root is generating a new PQ root.


This is completely standard practice, as exemplified by Let's Encrypt, 
DigiCert and Sectigo's pages describing their cross signs between the 
roots they operate [1,2,3]. There are no commercial relationships or 
sensitivities involved because the same organization controls both the 
signing and the cross-signed root.


I guess you assumed the alternative scenario where the roots belong to 
two different CAs. The standard terminology of referring to both as a 
cross-sign is regrettably vague.


Best,
Dennis

[1] Let's Encrypt X2 is cross signed by Let's Encrypt X1 
https://letsencrypt.org/certificates/


[2] Digicert G5 by the Digicert Global Root CA 
https://knowledge.digicert.com/tutorials/install-the-digicert-g5-cross-signed-root-ca-certificate


[3] Sectigo UserTrust is cross signed by Sectigo AAA 
https://support.sectigo.com/articles/Knowledge/Sectigo-Chain-Hierarchy-and-Intermediate-Roots




Ryan Hurst

On Mon, May 27, 2024 at 2:31 AM Dennis Jackson 
 wrote:


One of the key use cases proposed for Trust Expressions is
enabling a speedy deployment of PQC Certificates. I agree this is
an important use case to address, but I think a closer inspection
of the existing deployment options shows that Trust Expressions
does not provide any improvement or new functionality over
existing, already widely deployed solutions.

In particular, having each CA cross-sign their new PQC root with
their existing classical root. This does not require any new
functionalities or code changes in TLS clients or servers, does
not require coordination between CAs / Root Programs / Clients and
does not impose any performance impact on the connection (perhaps
surprisingly).

The rest of this message details the Trust Expressions proposal
for a PQC transition and compares the security and performance to
existing solutions.

*The Trust Expressions Proposal for the PQC Transition
*When we come to transition to PQC Certificates, the various Root
Programs will include various PQC Roots and start distributing
them to their clients. They will also configure their clients to
start advertising the relevant PQC / hybrid signature algorithms
in their signature_algorithms_cert TLS Extensions. TLS Servers
will decide whether to send their classical chain or their PQC
chain according to this extension.

The Trust Expressions authors plus quite a few folks on the list
have stated that this approach will require us to wait for all
major root programs to accept a given PQC Root and then for that
PQC root to be ubiquitously supported by all clients which also
advertise PQC Signature Support. Otherwise, we might send our new
PQ Chain to a client who only has an older set of PQ Roots, which
would cause a connection failure. This wait could take a long
time, even a year or more.

Trust Expressions proposes that by having clients indicate their
trust store label and version, we can mostly skip waiting for
ubiquity. Through the Trust Expression's negotiation, we can be
sure that we only send the PQC Root Certificate Chain to clients
that have already updated to trust it. Meanwhile, clients that
don't have PQC Signature support or do support the signatures but
don't have the new PQC root will continue to receive the old
classical chain and not enjoy any PQ Authentication.

*The Existing Alternative
*I believe this argument for the use of Trust Expressions
overlooks existing widely available deployment options for PQC
Certificates, which mean that we do not need to wait for multiple
root stores to include new PQC certs or for them to become
ubiquitous in clients. We will see how we can achieve the exact
same properties as Trust Expressions (no waiting for ubiquity, no
connection failures and PQ-Auth for all clients with the PQ Root)
without the need for any new designs or deployments.

When CAs create roots with new signature algorithms (e.g. ECDSA
Roots), it is common practice to cross-sign the new root with the
existing root (e.g. an RSA Root). This is the approach taken by
Let's Encrypt today, who have an older RSA Root (ISRG X1) and a
newer ECDSA Root (ISRG X2). X2 is cross signed by X1, and each of
the new ECDSA Intermediates are also cross-signed by X1 [1]. In
the context of RSA vs ECDSA

[marxmail] How Israel twists antisemitism claims to project its own crimes onto Palestinians

[Dennis Brasky]

What Israel and its supporters accuse Palestinians of inciting, Israeli
officials are openly declaring, and the Israeli army is prosecuting.

https://www.972mag.com/ihra-antisemitism-israel-inversion-projection/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30524): https://groups.io/g/marxmail/message/30524
Mute This Topic: https://groups.io/mt/106340302/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Why Chile has a Palestinian football team – the bigger history

[Dennis Brasky]

Chile is home to the largest population of Palestinians outside of the
Middle East. This Palestinian diaspora, which currently stands at just
under 500,000
 people,
has helped shape nearly a century of Chilean policy towards Palestine. At
the heart of this community, Palestino has not only served as a rallying
point for the diaspora, but also an instrument of cultural exchange and
diplomacy.

The first wave of Palestinian immigrants to arrive in Chile began in the
1850s, as people fled the Crimean war. A second wave of refugees arrived
before and during the first world war, as from 1909 the Ottoman empire extended
compulsory military service
 to include
young Christian and Jewish men. Many fled from conscription, while families
whose sons were forced into service lost their breadwinners and fell into
poverty, and so chose to leave Palestine.

The final major period of immigration from Palestine to Chile came
following the Nakba in 1948, when 700,000 Palestinians were forced from
their homes. Most migrants arrived at the port of Buenos Aires before
travelling across Argentina and entering into Chile over the Andes on
mules.
https://theconversation.com/why-chile-has-a-palestinian-football-team-the-bigger-history-229849


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30518): https://groups.io/g/marxmail/message/30518
Mute This Topic: https://groups.io/mt/106333463/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Access to Aid in Gaza Was Dire. Now, It’s Worse.

[Dennis Brasky]

The flow of aid into Gaza has shrunk so much in May that humanitarian
officials say their operations are at risk of shutting down, and that the
threat

of
widespread starvation

is
more acute than ever.
https://www.nytimes.com/interactive/2024/05/27/world/middleeast/gaza-food-aid
crossings.html



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30516): https://groups.io/g/marxmail/message/30516
Mute This Topic: https://groups.io/mt/106329376/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[TLS]Transitioning to PQC Certificates & Trust Expressions

[Dennis Jackson]

 but the leaf certificate with two-byte identifiers.


There are several alternatives available as well depending on the exact 
use case. For example, we could send only F1 (PQC Intermediate chaining 
to X3) and an X3 Root signed by X2 - ensuring there's only a single 
chain and no path building support required. Clients with the X3 PQC 
Root will not need to check the final ECDSA signatures, others will. 
With existing TLS Certificate Compression algorithms, this compresses 
slightly worse than the dual-intermediates chain, but Abridged Certs 
works just as effectively. AIA Chasing is also deployed in Chrome and 
could be used to fetch this final cross-sign certificate if desired, 
although I think stateless mechanisms like Certificate Compression with 
zlib are preferable.


In the event we'd like to make a second future transition, e.g. from a 
hybrid PQC signature scheme to a solely PQC scheme, or between PQC 
schemes, the same approach as above works just as well. I would fully 
expect by time we'd be considering a second transition, we'd either have 
mature deployment of solutions like intermediate suppression or abridged 
certs, or we'd be considering a move away from X.509 entirely to a 
newer, slimmer, PKI system.


Overall, I hope this is convincing that the Trust Expressions design 
does not achieve any improvements over existing technology for 
transitioning to PQC Certs and so I think we can set this proposed use 
case aside from the wider discussion.


*Wider Thoughts on the PQC Transition
*

In isolation, drafts like Abridged Certs and Trust Expressions can each 
deliver roughly the same size PQC Certificate Chains, able to compress 
down everything but the leaf certificate to just a couple of bytes. 
Depending on whether you expect PQC Signatures for SCTs, this gives an 
overall size of either ~4 KB - similar to RSA Chains today - or a rather 
unpalatable ~9 KB.


Although recent work on improved CT log implementations like Sunlight is 
vital for the ecosystem and fantastic to see, I'm still quite concerned 
about the long term story for a Post Quantum PKI with strong 
transparency guarantees. There are existing proposals like Merkle Tree 
Certificates which look to eliminate X.509 entirely and replace 
signatures with proofs of inclusions. I think these ideas are pretty 
exciting and with refinement could be a promising way forwards, but do 
have a few open problems that we still need to solve (especially on the 
transparency and availability aspects).


However, we do not need Trust Expressions to do Merkle Tree Certs or any 
alternative design, these features would necessarily need their own 
negotiation mechanism and so we should not confuse the two proposals.


Best,
Dennis

[1] https://letsencrypt.org/certificates/ *
*
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Stus-List Re: new jib sheet

[Dennis C. via CnC-List]

I use VPC.


--
Dennis C.
Touche' 35-1 #83
Mandeville, LA

On Sun, May 26, 2024 at 10:05 AM Bob Mann via CnC-List <
cnc-list@cnc-list.com> wrote:

> I snapped a  jib sheet on my 35 Saturday.  Suggestions on type of line for
> replacing?
>
> Bob
> Please show your appreciation for this list and the Photo Album site and
> help me pay the associated bills.  Make a contribution at:
> https://www.paypal.me/stumurray
> Thanks for your help.
> Stu
Please show your appreciation for this list and the Photo Album site and help 
me pay the associated bills.  Make a contribution at:
https://www.paypal.me/stumurray
Thanks for your help.
Stu

[marxmail] A century ago, anti-immigrant backlash almost closed America’s doors

[Dennis Brasky]

https://theconversation.com/a-century-ago-anti-immigrant-backlash-almost-closed-americas-doors-228589


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30510): https://groups.io/g/marxmail/message/30510
Mute This Topic: https://groups.io/mt/106318581/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Waiting for Gorbachev: The Chernyaev Diary, 1984

[Dennis Brasky]

*Washington D.C., May 25, 2024 - *The National Security Archive today marks
what would have been Anatoly Sergeyevich Chernyaev’s 103rd birthday with
the publication for the first time in English of his diary for 1984. A top
aide to Mikhail Gorbachev who later became one of the most important
scholars of the perestroika period, Chernyaev’s diary for 1984 documents
his time as deputy director of the International Department of the Central
Committee, responsible for the International Communist Movement (ICM).
Within three years, he would become Gorbachev’s chief foreign policy
adviser.

With the aim of preserving his diary as a historical document that should
be available to scholars, Chernyaev donated the original copy to the
National Security Archive. Every year, the Archive translates and posts
another installment of this extraordinary chronicle. Pulitzer Prize-winning
author David Hoffman has called the Chernyaev diary “irreplaceable” and
“one of the great internal records of the Gorbachev years.”

After the Soviet collapse, Chernyaev followed his president to the
Gorbachev Foundation, where he continued his scholarly work and also became
one the most important voices for transparency and historical truth. In the
1990s, he was a prolific writer, a participant in numerous conferences, and
a mentor to many Russian and Western scholars of the Cold War.

This is the final installment of the Chernyaev diary. With this
publication, the staff of the Archive’s Russia Programs has finished
translating all of the “public” portions of the diary, as selected by the
author himself, covering the years 1972-1991. This year is also the longest
and most varied of the diary in terms of the subjects it covers.

https://nsarchive.gwu.edu/briefing-book/russia-programs/2024-05-25/waiting-gorbachev-chernyaev-diary-1984


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30507): https://groups.io/g/marxmail/message/30507
Mute This Topic: https://groups.io/mt/106304401/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Biden and Congress are destroying International Law for Israel

[Dennis Brasky]

The current American threats to sanction the ICC could spell the death of
International Law. Whatever little hope people had for a just international
system will disappear.

https://mondoweiss.net/2024/05/biden-and-congress-are-destroying-international-law-for-israel/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30500): https://groups.io/g/marxmail/message/30500
Mute This Topic: https://groups.io/mt/106289247/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi Ryan,

On 23/05/2024 19:01, Ryan Hurst wrote:
Regarding the concern about government-mandated adoption of root 
certificates, I also care deeply about this issue. This is why I am 
disappointed by the one-sided nature of the conversation. I see no 
mechanism in this proposal that bypasses operator consent, and while 
governments do and will continue to force operators to make changes 
not in their interest, this proposal doesn't change that reality. 
Continuing to focus on this issue in this way detracts from the more 
constructive discussions happening in this thread.
The problem here is that fragmentation (which you acknowledge as a 
compelling concern) combined with making it much easier to deploy new 
CAs (a core goal of the draft) which together alters the power balance 
between the security community and governments in rather the wrong 
direction. I am not going to spend any further words on it here, but I'm 
disappointed you've engaged so dismissively in what has become a long 
discussion on a deeply complex topic.


The most compelling argument against Trust Expressions I see in the 
thread is the potential for fragmentation. However, the current 
conversation on this topic overlooks the existing fragmentation 
challenges faced by site operators. The primary concern I hear from 
these operators is the anxiety over changes related to cipher suites 
and certificates, fearing that these changes might inadvertently break 
services in exchange for security properties that their leadership 
isn’t asking for. Trust Expressions, in my view, offers a net-positive 
solution to this problem by allowing site operators to manage the 
trust anchor portion of this risk, which they cannot do effectively today.


Is it not rather the opposite, that this draft will give server 
operators an additional product space of choices and incompatibilities? 
With Trust Expressions, we must anticipate that CAs will need to jump 
through at least four separate hoops to provision a chain for each of 
the major root stores, as well as provision a chain for any past 
incompatible versions which are still popular. History does not suggest 
that CAs are particularly capable of managing these considerably more 
complex structures, given existing struggles with getting single chains 
correct.


Worse, we cannot expect Trust Expressions to become universal in any 
reasonable timeframe, meaning we still have the compatibility headache 
of existing and new clients with no Trust Expressions support.


At the same time, we are seeing more embedded devices being deployed 
without long-term maintenance strategies, automatic updates, or 
mechanisms to manage root store lists.


Can you evidence this? The UK and the EU have passed fairly sweeping 
laws over the past year to require that manufacturers provide long term 
maintenance and security updates for the entire lifecycle of new digital 
products [1,2]. The USA usually catches up eventually.


Better still, with the shift to PQ we have the best opportunity to adopt 
the Chrome Root Program's proposal for 7 year certificates. This would 
entirely fix this issue by pushing it from website operators to device 
manufacturers, where it should belong anyway :-), rather than creating a 
fragmented compatibility nightmare by embracing it and putting labels on 
it.


Best,
Dennis

[1] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
[2] 
https://www.gov.uk/government/news/new-laws-to-protect-consumers-from-cyber-criminals-come-into-force-in-the-uki





On Thu, May 23, 2024 at 10:40 AM Watson Ladd  
wrote:


On Thu, May 23, 2024 at 12:42 PM David Benjamin
 wrote:

>
> Of course, whether this property (whether servers can usefully
pre-deploy not-yet-added trust anchors), which trust expressions
does not have, even matters boils to whether a root program would
misinterpret availability in servers as a sign of CA
trustworthiness, when those two are clearly unrelated to each
other. Ultimately, the trustworthiness of CAs is a subjective
social question: do we believe this CA has *and will continue*
only sign true things? We can build measures to retroactively
catch issues like Certificate Transparency, but the key question
is fundamentally forward-looking. The role of a root program is to
make judgement calls on this question. A root program that so
misunderstands its role in this system that it conflates these two
isn't going to handle its other load-bearing responsibilities either.

As the old saw goes "past performance is no guarantee of future
results, but it sure helps". Moreover root programs have to balance
the benefits of including a CA against the costs. One of those
benefits is the number of sites that use it.

Sincerely,
Watson

>
> David
> ___
> TLS mailing list -- tls@ietf.org
&g

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

On 23/05/2024 17:41, David Benjamin wrote:

On Thu, May 23, 2024 at 11:09 AM Dennis Jackson 
 wrote


This is something that I believe David Benjamin and the other
draft authors, and I all agree on. You and Nick seem to have
misunderstood either the argument or the draft.

David Benjamin, writing on behalf of Devon and Bob as well:


By design, a multi-certificate model removes the ubiquity
requirement for a trust anchor to be potentially useful for a
server operator.

[...]

Server operators, once software is in place, not needing to be
concerned about new trust expressions or changes to them. The
heavy lifting is between the root program and the CA.

From the Draft (Section 7):


Subscribers SHOULD use an automated issuance process where the CA
transparently provisions multiple certification paths, without
changes to subscriber configuration.

The CA can provision whatever chains it likes without the
operator's involvement. These chains do not have to be trusted by
any clients. This is a centralized mechanism which allows one
party (the CA) to ship multiple chains of its choice to all of its
subscribers. This obviously has beneficial use cases, but there
are also cases where this can be abused.


Hi Dennis,

Since you seem to be trying to speak on my behalf, I'm going to go 
ahead and correct this now. This is not true. I think you have 
misunderstood how this extension works. [...]



Hi David,

The certification chains issued to the server by the CA comes tagged 
with a list of trust stores its included in. The named trust stores are 
completely opaque to the server. These chains and names may not be 
trusted by any client nor approved by any server, they are issued solely 
by the CA as opaque labels. These chains sit on the server and will not 
be used unless a client connects with the right trust store label but 
obviously can easily be scanned for by anyone looking to check how 
pervasively deployed the alternate trust store is.


Do you dispute any part of that? Most of what you wrote went off on a 
completely different tangent.


Of course, whether this property (whether servers can usefully 
pre-deploy not-yet-added trust anchors), which trust expressions does 
not have, even matters boils to whether a root program would 
misinterpret availability in servers as a sign of CA trustworthiness, 
when those two are clearly unrelated to each other.


Again, my primary concern here is not around the behavior of individual 
root stores, this is not relevant to the concern I'm trying to 
communicate to you. I know folks from all of the major root stores have 
great faith in their judgement and technical acumen.


My concern is that Trust Expressions upsets a fragile power balance 
which exists outside of the individual root stores. There is an eternal 
war between governments pushing to take control of root stores and the 
security community pushing back. This battle happens in parliaments and 
governments, between lawmakers and officials, not within root stores and 
their individual judgement largely does not matter to this war. The 
major advantages we as the security community have today are that:


    a) These attempts to take control for surveillance are nakedly 
obvious to the local electorate because crappy domestic roots have no 
legitimate purpose because they can never achieve any real adoption.


    b) If a root store were to bow to pressure and let in a root CA 
used for interception, every other country has an interest in preventing 
that. An international WebPKI means that we are either all secure, or 
all insecure, together.


Trust Expressions, though intended to solve completely different 
problems, will accidentally eradicate both of these advantages. Firstly, 
it provides a nice on ramp for a new domestic trust store, mostly 
through the negotiation aspect but also through the CA pre-distribution. 
Secondly, by enabling fragmentation along geographic boundaries whilst 
maintaining availability of websites. Without Trust Expressions, we 
cannot balkanize TLS. With Trust Expressions, we can and we know people 
who want to (not anyone in this thread).


If you still do not understand this wider context within which all of 
our work sits, I do not think further discussion between you and I is 
going to help matters.


I would suggest we focus our discussion on the use cases of Trust 
Expressions and how exactly it would work in practice - these concerns I 
shared earlier in the thread are solely technical and operational and 
you and I might be able to make better progress towards a common 
understanding.


Best,
Dennis
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[marxmail] Pentagon with blood on its hands refuses to make amends

[Dennis Brasky]

Yes, the number of deaths in Gaza in the last seven months is staggering.
At least, 35,000 Gazans

have
reportedly perished, including significant numbers of children

(and
that's without even counting the possibly 10,000

unidentified
bodies still buried under the rubble that now litters that 25-mile-long
stretch of land). But shocking as that might be (and it is shocking!), it
begins to look almost modest when compared to the numbers of civilians
slaughtered in America's never-ending Global War on Terror that began in
the wake of the 9/11 attacks and, as Nick Turse has reported

in
his coverage of Africa, never really ended.

In fact, the invaluable Costs of War project put the direct civilian death
toll

in
those wars at 186,694 to 210,038 in Iraq, 46,319 in Afghanistan, 24,099 in
Pakistan, and 12,690 in Yemen, among other places. And don't forget, as
that project also reports, that there could have been an estimated 3.6 to
3.8 million

(yes,
million!) "indirect deaths" resulting from the devastation caused by those
wars, which lasted endless years -- 20 alone for the Afghan one -- in South
Asia, the Middle East, and Africa.

https://tomdispatch.com/constant-killing/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30473): https://groups.io/g/marxmail/message/30473
Mute This Topic: https://groups.io/mt/106265044/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] military benefits to Americans serving in the Israeli army???

[Dennis Brasky]

A new bill in Congress would extend some U.S. military benefits to the
estimated 20,000 Americans currently carrying out the Gaza genocide as
members of the Israeli military.

https://mondoweiss.net/2024/05/new-bill-seeks-to-extend-u-s-military-benefits-to-americans-serving-in-the-idf/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30472): https://groups.io/g/marxmail/message/30472
Mute This Topic: https://groups.io/mt/106264960/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi David,

On 23/05/2024 14:07, David Adrian wrote:
There is certainly a discussion to be had about how well Trust 
Expressions solves problems experienced by the HTTPS ecosystem and the 
Web PKI today. However, that requires moving past repeated, 
unsubstantiated claims about how Trust Expressions enables government 
surveillance, something has been repeatedly debunked by multiple 
people in this thread, all of whom are attempting to discuss in good 
faith. And yet, each time someone does this, you change the shape of 
your argument, claim there is more nuance that no one except you can 
see, and describe some easily debunked partial scenario that you 
believe to be worse.


This is, politely, hogwash and a rather shabby attempt to portray this 
as a one-sided discussion.


I have presented a single consistent argument about how Trust 
Expressions solves a key deployment challenge for parties trying to 
perform this kind of abuse. This argument has not changed over the 
course of the thread, as I noted in my latest reply to Nick, this was 
just a summary of the previous discussion.


This argument has been supported by others in the thread, in particular 
by Stephen Farrell:


Having read the draft and the recent emails, I fully agree with 
Dennis' criticisms of this approach. I think this is one that'd  best 
be filed under "good try, but too many downsides" and left at that. 


Meanwhile, the four loudest voices who deny there are legitimate 
concerns around this proposal all work for the same team at Google and 
have announced their intent to prototype this technology already [1].


The majority of the participants in this thread have engaged with these 
discussions with curiosity and have yet to voice any conclusion. I am 
sure they will do so when they have made up their minds.


My personal reading has been that folks who have engaged in the 
discussion would agree there is both reasonable concern about how 
effective T.E. is at solving the problems it claims to and that the 
risks of abuse cannot be dismissed as easily as the authors would like.


It may be worth taking a step back, and considering if the people you 
have worked with for nearly a decade or more, and who have been 
instrumental in improving TLS over the years, have truly suddenly 
decided to pivot to attempting to backdoor mass surveillance through 
the IETF.


I have noted throughout that this is a complex topic which reasonable 
people may disagree on. I have a great deal of respect for the authors 
who I know are acting out of genuine intent to improve the world. We 
simply disagree on whether the proposed design is likely to effective at 
solving the problems it sets out and how seriously it could be abused by 
others.




A few replies relating to surveillance are inline.

-dadrian

> I think we have to agree that Trust Expressions enables websites to 
adopt new CA chains regardless of client trust and even builds a 
centralized mechanism for doing so. It is a core feature of the design.


No one has to agree to this because you have not backed this claim at 
all. Nick sent two long emails explaining why this was not the case, 
both of which you have simply dismissed [...]


This is something that I believe David Benjamin and the other draft 
authors, and I all agree on. You and Nick seem to have misunderstood 
either the argument or the draft.


David Benjamin, writing on behalf of Devon and Bob as well:

By design, a multi-certificate model removes the ubiquity requirement 
for a trust anchor to be potentially useful for a server operator.


[...]

Server operators, once software is in place, not needing to be 
concerned about new trust expressions or changes to them. The heavy 
lifting is between the root program and the CA.

From the Draft (Section 7):

Subscribers SHOULD use an automated issuance process where the CA 
transparently provisions multiple certification paths, without changes 
to subscriber configuration.
The CA can provision whatever chains it likes without the operator's 
involvement. These chains do not have to be trusted by any clients. This 
is a centralized mechanism which allows one party (the CA) to ship 
multiple chains of its choice to all of its subscribers. This obviously 
has beneficial use cases, but there are also cases where this can be abused.


Can you explain, specifically, the government and site action that you 
expect that will result in surveillance, keeping in mind that ACME 
_already_ allows the CA to provide a bundle of untrusted 
intermediates? What is the chain of events here? What are the actions 
you see taken by a government, a CA, site owners, and root programs?


CA provided intermediates doesn't offer any long term transition without 
Trust Expressions. You could absolutely stuff the domestic CA in there 
on some short term basis, but you're never going to be able to take out 
the WebPKI recognized intermediate (for all the folks connecting without 
th

[marxmail] With Biden’s Bear Hug of Israeli Atrocities, World’s View of American Democracy Craters

[Dennis Brasky]

https://www.juancole.com/2024/05/atrocities-american-democracy.html


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30469): https://groups.io/g/marxmail/message/30469
Mute This Topic: https://groups.io/mt/106262886/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi Nick,

I think the issues around risk have a great deal of nuance that you're 
not appreciating, but which I've tried to lay out below. I appreciate 
that rational reasonable people can absolutely disagree on how they 
weigh up these risks, but I think we have to agree that Trust 
Expressions enables websites to adopt new CA chains regardless of client 
trust and even builds a centralized mechanism for doing so. It is a core 
feature of the design.


On the issues around benefit, you've repeated the high level talking 
points around PQ, adopting new CAs and supporting older devices, but 
these talking points don't pan out on closer inspection.


The central problem is that whilst Trust Expressions introduces a 
negotiation mechanism at the TLS layer, it is only moving the pain up 
the stack, without actually solving anything. To actually solve these 
problems, Trust Expressions envisages that either website operators are 
doing a complex dance with multiple CAs to enable the universal 
compatibility they already enjoy today or that new CAs are forming 
business relationships with incumbent CAs, identically as they would for 
a cross sign. In both cases, we're adding a lot more complexity, 
fragmentation and pain, for no actual return.


A detailed response is inline below.

Best,
Dennis

On 22/05/2024 07:28, Nick Harper wrote:

The second way this could happen is that the government compels a 
browser to add a CA to their root store regardless of whether it 
complies with root store policy, implicitly stating that this CA will 
misissue certificates. The browser's choice is to comply or leave the 
market. Until this new CA is in a trust store advertised by clients, 
there's no incentive for server operators to get a certificate issued 
by that CA, as there are no clients for it to present that cert to.
This is incorrect. Governments have a wide range of incentives available 
to them to encourage adoption by websites, including simply making it a 
legal requirement. Currently, none of those incentives are strong enough 
to overcome the fact that the website would become simply inoperable 
without Trust Expressions.
Thus, server adoption is no factor in the government's pressure to 
compel a browser to add their CA, and I see the same probability of 
this being successful as in the current state of the world without 
Trust Expressions.
The conclusion that server adoption has no role in government pressure 
doesn't follow from any of the argument that you made and is in any 
case, wrong.


Government capability to compel browsers is fundamentally one of 
legitimacy. In democracies, this usually plays out in debates between 
elected lawmakers who will either support or oppose new legislation 
impacting browsers. Website adoption is absolutely a factor in this 
debate. "A large fraction of our domestic websites have adopted our new 
domestic certificates, but American browsers refuse to trust them 
leaving us dependent on foreign infrastructure" is a much more powerful 
argument than "we made a new CA that no one uses, pretty please can we 
force browsers to trust it".


A substantial issue that you didn't pick up on is how Trust Expressions 
changes government incentives to perform this kind of mass surveillance. 
Whilst having your domestic root CA ship in clients does enable 
surveillance, it's not especially useful when no websites use that root 
CA, so targets can tell when their connection is being intercepted. 
Governments therefore either have two choices: MiTM everything (a 
substantial hurdle to have passed into law) or compel adoption by 
websites of the domestic CA (so that MiTM certs blend in with real 
ones). This latter path is substantially easier from the perspective of 
lawmaking and is only possible with Trust Expressions (otherwise the 
adopting sites would become inaccessible. As noted earlier in the 
thread, this approach with Trust Expressions also scales nicely, 
allowing many countries to do this in parallel with the website using 
the domestic CA of each one.



> The real problem here is that you've
> (accidentally?) built a system that makes it much easier to adopt and
> deploy any new CA regardless of trust, rather than a system that makes
> it easier to deploy & adopt any new *trusted* CA.

I disagree that it makes it easier to adopt and deploy a new CA 
*regardless of trust*. Trust Expressions only makes it easier to 
deploy a CA that is in a trust store advertised by clients. If a CA is 
in a client's trust store, that to me sounds like a *trusted CA*.


Without Trust Expressions, web servers are locked into one certificate 
chain which needs to be widely trusted. With Trust Expressions, web 
servers can add arbitrary certificate chains regardless of client trust, 
and CAs are empowered to ship additional chains without the operator's 
consent. This makes it much easier to deploy a new CA regardless of 
trust. Neither the operator, not t

[Bug 2063124] Re: UI shows loading screen for entire install while doing fully automated install

[Dennis Loose]

** Changed in: ubuntu-desktop-provision
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063124

Title:
  UI shows loading screen for entire install while doing fully automated
  install

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2063124/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063124] Re: UI shows loading screen for entire install while doing fully automated install

[Dennis Loose]

Thanks Olivier, you're right - the UI's status monitor currently enters
a 'null' state which it can't recover from when subiquity restarts. We
should probably handle this more gracefully and attempt to re-connect to
subiquity a certain number of times.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063124

Title:
  UI shows loading screen for entire install while doing fully automated
  install

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/2063124/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[marxmail] Imperial Ambitions

[Dennis Brasky]

The United States took shape in the age of European empires, and it didn’t
take long for the new nation to embark on its own imperial projects. This
exhibit traces 500 years of empire-building efforts, from the Age of
Exploration to the North American Indian Wars to the extension of American
military and economic power over island nations from the Caribbean to the
Pacific. It also considers America’s role in the 20th-century clashes
between global empires, and the extent to which 21st-century conflicts are
still driven by the imperative to dominate far-flung peoples and lands.
https://www.bunkhistory.org/exhibits/imperialism


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30462): https://groups.io/g/marxmail/message/30462
Mute This Topic: https://groups.io/mt/106247515/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] America’s Monster – How the US Backed kidnapping, Torture and Murder in Afghanistan

[Dennis Brasky]

https://www.nytimes.com/2024/05/22/world/asia/afghanistan-abdul-raziq.html


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30461): https://groups.io/g/marxmail/message/30461
Mute This Topic: https://groups.io/mt/106246764/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] NY Times video - 2 weeks inside Gaza's ruined hospitals

[Dennis Brasky]

>
> The many articles on the effects of the war on the medical system, do not
>> seem quite as powerful to me as this. And Biden objects to Israeli leaders
>> being charged with crimes by the ICC? How many Israeli hi\ospitals has
>> Hamas attacked and destroyed???
>> https://www.nytimes.com/2024/05/21/opinion/gaza-hospital-collapse.html
>> 
>>
>>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30460): https://groups.io/g/marxmail/message/30460
Mute This Topic: https://groups.io/mt/106246634/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Fedora Workstation 40 aarch64 download -- How to run Live CD installer?

[Dennis Gilmore via devel]

https://ausil.fedorapeople.org/Fedora-Workstation-Live-aarch64-40-20240417.n.0.iso
is the last ISO built for a nightly compose for F40. It gives you the
prerelease warning but is very close to GA.

Dennis

On Wed, May 22, 2024 at 7:40 AM Adam Williamson
 wrote:
>
> On Tue, 2024-05-21 at 20:15 -0400, Neal Gompa wrote:
> > On Tue, May 21, 2024 at 8:11 PM Samuel Sieb  wrote:
> > >
> > > On 5/21/24 5:08 PM, Brian Masney wrote:
> > > > I want to put Fedora 40 on my Lenovo Thinkpad x13s laptop, which is an
> > > > aarch64-based laptop with a Qualcomm SoC. I downloaded the Fedora raw
> > > > image from [1], and I can boot from USB using the directions at [2].
> > > > All of the other supported architectures have an ISO available,
> > > > however aarch64 only has a raw image available.
> > > >
> > > > In the past, I would dd the Fedora image directly to my nvme drive,
> > > > however this time I'd like to go through the installer so that I can
> > > > easily setup LUKS encryption on my nvme drive through the installer.
> > > > The raw image doesn't have the installer, and I didn't have luck
> > > > installing the anaconda-livecd package.
> > > >
> > > > Is there a Live ISO available for aarch64 anywhere with an installer?
> > >
> > > https://dl.fedoraproject.org/pub/fedora/linux/releases/40/Workstation/aarch64/iso/
> >
> > That is the experimental osbuild one. There is no official ISO, as it
> > failed to build. It affected Fedora KDE and other variants too. :(
>
> Yes, that.
>
> Beyond that, Dennis Gilmore has been poking at Fedora on the x13s for a
> bit, and has run into some issues you might want to be aware of. See
> https://bugzilla.redhat.com/show_bug.cgi?id=2254940 and
> https://bugzilla.redhat.com/show_bug.cgi?id=2264794 .
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Discover] [Bug 487333] Discover doesnt update

[Dennis]

https://bugs.kde.org/show_bug.cgi?id=487333

--- Comment #2 from Dennis  ---
Thank you very very much!


Στις 22/5/24 10:16, ο/η Harald Sitter έγραψε:
> https://bugs.kde.org/show_bug.cgi?id=487333
>
> Harald Sitter  changed:
>
> What|Removed |Added
> 
>   CC||sit...@kde.org
>   Resolution|--- |WAITINGFORINFO
>   Status|REPORTED|NEEDSINFO
>
> --- Comment #1 from Harald Sitter  ---
> what's the output of
>
> flatpak repair
> flatpak update
>

-- 
You are receiving this mail because:
You are watching all bug changes.

[kstars] [Bug 487342] New: Capture Module under file settings cannot change directory

[Dennis]

https://bugs.kde.org/show_bug.cgi?id=487342

Bug ID: 487342
   Summary: Capture Module under file settings cannot change
directory
Classification: Applications
   Product: kstars
   Version: 3.7.0
  Platform: Other
OS: macOS
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mutla...@ikarustech.com
  Reporter: dennisjcoll...@gmail.com
  Target Milestone: ---

***
If you're not sure this is actually a bug, instead post about it at
https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
When selecting the folder button next to the Directory field under File
Settings in the Capture Module nothing happens. A spinning color wheel appears
indicating it is attempting the operation but it eventually just times out and
nothing happens. 

STEPS TO REPRODUCE
1. goto capture module
2. select folder icon to change directory under file settings
3. nothing happens

OBSERVED RESULT
Spinning colored wheel and eventually times out

EXPECTED RESULT
window appear to change directory where images will be saved to

SOFTWARE/OS VERSIONS
Windows: 
macOS: version 14.4.1 Sonoma
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

Hi Nick,

On 21/05/2024 19:05, Nick Harper wrote:

[...]

Perhaps there are additional ways to use Trust Expressions to censor 
the web that are more practical and more useful than the existing 
techniques that I didn't consider. There are most certainly other 
forms of domestic control of the Web that I didn't consider. From my 
analysis, if I were a government looking to enable surveillance and 
domestic control of the Web, I don't see Trust Expressions as 
something that unlocks new options or makes existing techniques 
easier/more reliable. It is at most something to keep in mind as 
technology evolves. Maybe I'm not very imaginative, and you've 
imagined much more interesting ways a government might surveil the web 
or attempt to control it using Trust Expressions.


This thread is now 40+ messages deep and I guess you might have not seen 
much of the previous discussion. I actually agree with much of your 
analysis, but it focused on the wrong question, as I wrote earlier in 
this thread:


The question we're evaluating is NOT "If we were in a very unhappy 
world where governments controlled root certificates on client devices 
and used them for mass surveillance, does Trust Expressions make 
things worse?" Although Watson observed that the answer to this is at 
least 'somewhat', I agree such a world is already maxed at 10/10 on 
the bad worlds to live in scale and so it's not by itself a major 
problem in my view.


The actual concern is: to what extent do Trust Expressions increase 
the probability that we end up in this unhappy world of government CAs 
used for mass surveillance?


On 21/05/2024 19:05, Nick Harper wrote:


I'd be interested to hear details on what those are.

Messages [1,2,3,4] of this thread lay out these details at length.

Besides these concerns which are unaddressed so far, much of the recent 
discussion has focused on establishing what problem(s) Trust Expressions 
actually solves and how effective a solution it actually is.


Looking forward to your thoughts on either or both aspects.

Best,
Dennis

[1] https://mailarchive.ietf.org/arch/msg/tls/LaUJRHnEJds2Yfc-t-wgzkajXec/

[2] https://mailarchive.ietf.org/arch/msg/tls/zwPvDn9PkD5x9Yw1qul0QV4LoD8/

[3] https://mailarchive.ietf.org/arch/msg/tls/9AyqlbxiG7BUYP0UD37253MeK6s/

[4] https://mailarchive.ietf.org/arch/msg/tls/fxM4zkSn0b8zOs59xlH6uy8P7cE/



___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: [FFmpeg-devel] [PATCH 01/13] avformat/flvenc: Implement support for multi-track video

[Dennis Sädtler via ffmpeg-devel]

> From: Dennis Sädtler via ffmpeg-devel 

I wonder what happened here, did I make a mistake when submitting the
original patch to the ML so the actual commit author name/email got
lost?

Should be the same as the signed-off section based on the repo I
submitted it from:
https://github.com/derrod/ffmpeg/commit/25f1700cffa00fcd04bcc27efce077a93e7f5142

Cheers,
Dennis
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[Discover] [Bug 487333] New: Discover doesnt update

[Dennis]

https://bugs.kde.org/show_bug.cgi?id=487333

Bug ID: 487333
   Summary: Discover doesnt update
Classification: Applications
   Product: Discover
   Version: 5.27.11
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: discover
  Assignee: plasma-b...@kde.org
  Reporter: dsou...@gmx.com
CC: aleix...@kde.org
  Target Milestone: ---

Created attachment 169685
  --> https://bugs.kde.org/attachment.cgi?id=169685=edit
Themessage received

***
If you're not sure this is actually a bug, instead post about it at
https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY


STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
I am receiving an error:
Aborted due to failure (While trying to apply extra data: apply_extra script
failed, exit status 256)
and discover is not updating applications (Kubuntu 24.04).

-- 
You are receiving this mail because:
You are watching all bug changes.

[marxmail] J Street and the dead-end of liberal American Zionism

[Dennis Brasky]

The crux of our commentary 10 years ago holds even more terribly true
today, after another decade of systemic, often-lethal cruelty toward
Palestinian people: J Street continues its attempt to create a humane lobby
group for Israel, without questioning the manifestly unjust — and thus
perpetually unstable — settlement and expulsion project that created Israel
in the first place and has sustained it ever since. In essence, while
presenting itself as a caring alternative to Netanyahu-brand extremism,
liberal Zionism’s yearning for “peace” assumes perpetuation of basic
Israeli transgressions and gains over the last 75 years, while calling for
acceptance and submission from a defeated and colonized people.



Long story short, the dream of humanistic Zionism is collapsing, but — like
other entrenched Jewish groups and a declining number of American Jews — J
Street is desperate to keep the fantasy on life support. The nostrum of a
two-state solution for the small tormented land of Palestine is more and
more flimsy, but organizations like J Street and a large majority of
elected Democrats refuse to concede that it has been made nonsensical by
Israel’s ever-expanding settlements and escalating Jewish nationalism
comfortable with inflicting genocide on Palestinian people.



Likewise, if J Street officials understand the state of Israeli politics,
it doesn’t show. The organization’s officials also keep talking about a
Palestinian state. But in reality, the “two-state solution” has become only
a talking-point solution for liberal American Zionists, elected Democrats,
and assorted pundits who keep trying to dodge what Israel has actually
become.

https://www.counterpunch.org/2024/05/21/the-dead-end-of-liberal-american-zionism/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30443): https://groups.io/g/marxmail/message/30443
Mute This Topic: https://groups.io/mt/106227786/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Long Live US hypocrisy! Washington Celebrates ICC ruling against Russia, Condemns Warrant Request for Israel

[Dennis Brasky]

This reaction shows that the Biden administration does not respect
international law and does not care that Putin committed crimes under it,
but just wants to stick it to Putin. It is personalistic, not a matter of
law. Because if the law was at issue, it should apply to everyone,
including (especially) Benjamin Netanyahu, the Butcher of Gaza.

https://www.juancole.com/2024/05/washington-celebrates-condemns.html

...

Arizona-based Internet domain company NameCheap ended all service to Russia
over the invasion of Ukraine but has now registered an Israeli website
targeting Palestinian children. Activists are calling out the company's
complicity in war crimes.

https://mondoweiss.net/2024/05/israels-extortion-leaflets-and-namecheap-how-to-do-corporate-accountability-during-a-genocide/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30441): https://groups.io/g/marxmail/message/30441
Mute This Topic: https://groups.io/mt/106226396/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[kstars] [Bug 487322] New: Guide Module shows FOV as 35.2 x 12015.8 using simulator guide scope. Can't see stars to guide by.

[Dennis]

https://bugs.kde.org/show_bug.cgi?id=487322

Bug ID: 487322
   Summary: Guide Module shows FOV as 35.2 x 12015.8 using
simulator guide scope. Can't see stars to guide by.
Classification: Applications
   Product: kstars
   Version: 3.7.0
  Platform: Other
OS: macOS
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mutla...@ikarustech.com
  Reporter: dennisjcoll...@gmail.com
  Target Milestone: ---

***
If you're not sure this is actually a bug, instead post about it at
https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
Using simulators I apparently get a glitch with FOV in guide module. If I
select sample guide scope it reports fov of 35.2 x 12015.8. 

Interestingly, for the primary train using Sample Primary 700@F/5.8 it shows
FOV is 24.1 x 17.9. However as an attempt to troubleshoot I also set the Sample
Primary scope for secondary train and it shows the same scope now with a field
of view of 15.1 x 5149.6.

STEPS TO REPRODUCE
1. using simulator choose use sample guide 300@F/6.0
2. In guide module select secondary train
3. Scope / Lens Info shows FOV 35.2 x 12015.8

OBSERVED RESULT
Can't see any stars to track

EXPECTED RESULT
Track multi stars

SOFTWARE/OS VERSIONS

macOS: 

(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: Can't Add Bookshare Books to VoiceDream

[Dennis Long]

One other question that’s just popped into my brain. What if they paid for a subscription again in good face that these features would work you are now in violation of the App Store agreement which states you cannot take features away you took features away and didn’t tell the user so are you going to refund their money or are you going to restore functionality?Dennis LongSent from my iPhone 15 Pro MaxOn May 21, 2024, at 5:01 AM, Arnold Schmidt  wrote:I remember that CC is using 16.x, I had suspected that that was the problem.  I think that is unfortunate that they start dropping features so soon for those who are using older ios's. Even Apple gives the ios 16 users security updates for this year.  I know a lot of people who are still using their iphone 8 every day, and one who still uses a 7 with ios 15. Not everybody can, or wants to,  afford that 15 pro max. And those who are still using their iphone 8 are about to be two generations out of date. Sent from  Arnold's  iPhone S E 3On May 20, 2024, at 6:29 PM, Richard Turner  wrote:If you are using iOS 16.x that could be the issue. A friend discovered yesterday that after updating from iOS 16 something to 17.5 the download button was back. I'd recommend writing to the support folks through the Voice Dream, Settings, Email support.Richard, USA“Grandma always told us, “Be careful when you pray for patience. God stores it on the other side of Hell and you will have to go through Hell to get it.”-- Cedrick Bridgeforth My web site: https://www.turner42.com/ On May 20, 2024, at 3:18 PM, CC  wrote:Folks, Version 4.34.4 is now available. Still no download option. Going to bookshare on the web, downloading to files app, then transferring to VDR, is doable, but cumbersome. On Sunday, May 12, 2024 at 9:07:58 PM UTC-4 Richard Turner wrote:First Bookshare's response doesn't make a lot of sense to me. Once the book is downloaded, you do not need internet access. So, I'm not sure what they mean. I never had any issue switching to another app, and then coming back to Voice Dream and continuing reading a book. Richard, USA“Grandma always told us, “Be careful when you pray for patience. God stores it on the other side of Hell and you will have to go through Hell to get it.”-- Cedrick Bridgeforth My web site: https://www.turner42.com/ On May 12, 2024, at 2:27 PM, Jenifer Barr <claud...@gmail.com> wrote:When I contacted bookshare about this... they said sometimes books are taken offline due to copyright etc. The skeliton is still there but the book is taken down. (shrug) Sent from my iPhoneOn May 12, 2024, at 5:10 PM, Jody ianuzzi <thunderw...@gmail.com> wrote:Oh I can add books from Bookshare to my voic Voice Dream reader but I have another problem. If I go to a different app and then go back to the Voice Dream reader and hit play nothing happens. I have to remove it from the app switcher and start again and then it's OK.Has anyone else had this problem?JODYTo Boldly Go   thunderw...@gmail.com "What's within you is stronger than what's in your way."  NO BARRIERS  Erik WeihenmayerOn May 12, 2024, at 12:28 PM, CC <ccunqu...@gmail.com> wrote:Thanx, Richard. A three finger swipe down, refreshed the, recently updated element. There were 12 updates waiting to be integrated. Voicedream version 4.34.3, still offers no download option in bookshare.  On Sunday, May 12, 2024 at 11:02:10 AM UTC-4 Richard Turner wrote:Now, it not showing up in the updates list is very, very strange.That would point to an Apple issue.When I check for updates, I do a triple tap on the app store icon, then swipe to updates and double tap.  Then, touch where it says previously Updated and do a three finger swipe down to refresh the screen.I have found that has been the only reliable way for me to get all updates available to show up consistently. If Voice Dream doesn’t show up then, I think there is a bigger issue with your phone.Richard, USA"It's no great honor to be blind, but it's more than a nuisance and less than a disaster. Either you're going to fight like hell when your sight fails or you're going to stand on the sidelines for the rest of your life." -- Dr. Margaret Rockwell Phanstiehl Founder of Audio Description (1932-2009) My web site: https://www.turner42.com From: vip...@googlegroups.com <vip...@googlegroups.com> On Behalf Of CCSent: Sunday, May 12, 2024 7:47 AMTo: VIPhone <vip...@googlegroups.com>Subject: Re: Can't Add Bookshare Books to VoiceDream Two new problems. Version 4.34.2 still gives no download option and voicedream updates don't appear in new app store updates. It seems I must search for the voicedream app, open the voicedream result, then click on, update button. All other app updates appear as expected. On Sunday, May 12, 2024 at 12:31:21 AM UTC-4 Richard Turner wrote:Well, to test this, I went and turned audio ducking on, but on or off, all audio books play just fine for me. So that may have nothing to do with your is

Re: Can't Add Bookshare Books to VoiceDream

[Dennis Long]

First, if this is what’s being done that’s wrong second to not put it in the release notes again is wrong. This is what Jonathan Mohsen was talking about when he said clear and concise release notes! Clearly this company has not learned a thing! Every other company that I have seen do this first of all supports at least the previous version of iOS if not, two versions back! Second, they are honest And upfront This company is not honest and transparent!!! Every day that goes by, it is more and more likely I will not ever again use their app!! This app had a Sterling reputation at one time and with all the little hidden things they pull it goes to crap! This is ridiculous. It’s one thing if that’s what you decide to do. It’s another thing to not disclose it entirely and it’s wrong . Dennis LongSent from my iPhone 15 Pro MaxOn May 21, 2024, at 5:01 AM, Arnold Schmidt  wrote:I remember that CC is using 16.x, I had suspected that that was the problem.  I think that is unfortunate that they start dropping features so soon for those who are using older ios's. Even Apple gives the ios 16 users security updates for this year.  I know a lot of people who are still using their iphone 8 every day, and one who still uses a 7 with ios 15. Not everybody can, or wants to,  afford that 15 pro max. And those who are still using their iphone 8 are about to be two generations out of date. Sent from  Arnold's  iPhone S E 3On May 20, 2024, at 6:29 PM, Richard Turner  wrote:If you are using iOS 16.x that could be the issue. A friend discovered yesterday that after updating from iOS 16 something to 17.5 the download button was back. I'd recommend writing to the support folks through the Voice Dream, Settings, Email support.Richard, USA“Grandma always told us, “Be careful when you pray for patience. God stores it on the other side of Hell and you will have to go through Hell to get it.”-- Cedrick Bridgeforth My web site: https://www.turner42.com/ On May 20, 2024, at 3:18 PM, CC  wrote:Folks, Version 4.34.4 is now available. Still no download option. Going to bookshare on the web, downloading to files app, then transferring to VDR, is doable, but cumbersome. On Sunday, May 12, 2024 at 9:07:58 PM UTC-4 Richard Turner wrote:First Bookshare's response doesn't make a lot of sense to me. Once the book is downloaded, you do not need internet access. So, I'm not sure what they mean. I never had any issue switching to another app, and then coming back to Voice Dream and continuing reading a book. Richard, USA“Grandma always told us, “Be careful when you pray for patience. God stores it on the other side of Hell and you will have to go through Hell to get it.”-- Cedrick Bridgeforth My web site: https://www.turner42.com/ On May 12, 2024, at 2:27 PM, Jenifer Barr <claud...@gmail.com> wrote:When I contacted bookshare about this... they said sometimes books are taken offline due to copyright etc. The skeliton is still there but the book is taken down. (shrug) Sent from my iPhoneOn May 12, 2024, at 5:10 PM, Jody ianuzzi <thunderw...@gmail.com> wrote:Oh I can add books from Bookshare to my voic Voice Dream reader but I have another problem. If I go to a different app and then go back to the Voice Dream reader and hit play nothing happens. I have to remove it from the app switcher and start again and then it's OK.Has anyone else had this problem?JODYTo Boldly Go   thunderw...@gmail.com "What's within you is stronger than what's in your way."  NO BARRIERS  Erik WeihenmayerOn May 12, 2024, at 12:28 PM, CC <ccunqu...@gmail.com> wrote:Thanx, Richard. A three finger swipe down, refreshed the, recently updated element. There were 12 updates waiting to be integrated. Voicedream version 4.34.3, still offers no download option in bookshare.  On Sunday, May 12, 2024 at 11:02:10 AM UTC-4 Richard Turner wrote:Now, it not showing up in the updates list is very, very strange.That would point to an Apple issue.When I check for updates, I do a triple tap on the app store icon, then swipe to updates and double tap.  Then, touch where it says previously Updated and do a three finger swipe down to refresh the screen.I have found that has been the only reliable way for me to get all updates available to show up consistently. If Voice Dream doesn’t show up then, I think there is a bigger issue with your phone.Richard, USA"It's no great honor to be blind, but it's more than a nuisance and less than a disaster. Either you're going to fight like hell when your sight fails or you're going to stand on the sidelines for the rest of your life." -- Dr. Margaret Rockwell Phanstiehl Founder of Audio Description (1932-2009) My web site: https://www.turner42.com From: vip...@googlegroups.com <vip...@googlegroups.com> On Behalf Of CCSent: Sunday, May 12, 2024 7:47 AMTo: VIPhone <vip...@googlegroups.com>Subject: Re: Can't Add Bookshare Books to VoiceDream Two new problems. Version 4.34.2 still gives no d

[marxmail] Ocean water is rushing miles underneath the ‘Doomsday Glacier’ with potentially dire impacts on sea level rise

[Dennis Brasky]

Thwaites, which already contributes 4% to global sea level rise, holds
enough ice to raise sea levels by more than 2 feet. But because it also
acts as a natural dam to the surrounding ice in West Antarctica, scientists
have estimated

its
complete collapse could ultimately lead to around 10 feet of sea level rise
— a catastrophe for the world’s coastal communities.

https://www.cnn.com/2024/05/20/climate/doomsday-glacier-melt-antarctica-climate-intl



>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30432): https://groups.io/g/marxmail/message/30432
Mute This Topic: https://groups.io/mt/106215599/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Stus-List Re: C 35 MK I interior

[Dennis C. via CnC-List]

Joe,

This must be a very early 35.  It's listed as a 1970.  I found what may be
it in the USCG vessel search under Vessel Number 527443 but no hull number
is shown.

It is quite different from any 35 I've ever seen.  The cabinetry is very
different.  There are no frames around the above seat storages or hanging
locker accesses.  The bulkhead under the seats is wood, not fiberglass.
The port above the hanging locker is unusual.  The one in the head is not.
(Hull 61 has one of those.)

Dorades?  Go figure.

No wrap around seat backs.

The V-berth bureau drawers lack finger holes.  The fiddles on the bureaus
are different.

The engine compartment appears to be wood.  The inboard navstation bulkhead
is curved.  The 45 angle on the inboard end of the navstation lift up is
different.

The galley sink is rotated 90 degrees from Touche's.  The head sink is
rectangular.  Most are round.

No fiberglass step under the V-berth filler piece.  Might have been removed?

Most of these differences look factory.  I don't think they were owner
modifications.

I'm guessing this boat was one or two steps removed from the C 35
prototype.

--
Dennis C.
Touche' 35-1 #83
Mandeville, LA

On Mon, May 20, 2024 at 11:13 AM Joe Della Barba via CnC-List <
cnc-list@cnc-list.com> wrote:

> Was this stock? I cannot recall seeing any other 35 with this much teak:
>
> https://www.yachtworld.com/yacht/1970-c$c-35-mk-i-9350708/
>
>
>
>
>
> Joe Della Barba
>
> Coquina C 35 MK I
>
> Kent Island MD USA
>
>
>
Please show your appreciation for this list and the Photo Album site and help 
me pay the associated bills.  Make a contribution at:
https://www.paypal.me/stumurray
Thanks for your help.
Stu

[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson]

ith this assertion and don’t see websites’ deployment as a
   factor in trust store inclusion decisions in this scenario.

I asked why you believed that. Flat denial of the direct connection 
between making it easier to deploy a new CA (regardless of any root 
store inclusion) and the ease of deploying a new CA for bad purposes is 
a weird hill to die on.


   Ifwe had Trust Expressions deployed today, how would life be
   better for LE / Cloudflare or other impacted parties?

   It isn’t necessary for older device manufacturers to adopt Trust
   Expressions. Rather, Trust Expressions would be adopted by modern
   clients, allowing them to improve user security without being held
   back by older clients that don’t update. Servers may still need to
   navigate intersections and fingerprinting for older clients, but
   this will be unconstrained by modern ones. It will also become
   simpler, with fingerprinting less prevalent, as older clients fall
   out of the ecosystem.

You seem to be agreeing that it wouldn't solve any of the issues which 
people have come to the list to talk about. Rather, you're now anchoring 
your claims around improving security. But its totally unclear what 
security benefits you're actually delivering.


   To pick an example you've repeatedly highlighted, can you
   clarify how Trust Expressions will speed the transition to a PQ
   PKI? Specifically, how much earlier do you expect a given site
   to be able to deploy a PQ cert chain in the case of TE adoption
   vs without TE adoption (and why)?


   The transition benefits are briefly summarized in Section 9.2. We
   anticipate a PQ transition will result in many PQ roots coming
   online in a short time. It is implausible that every root program
   will qualify them at the same time and in the same order.

   That means, during the transition, different trust stores will have
   different subsets of the final “common” PQ root set. (But, again, as
   root programs do not and cannot actually coordinate, it is not a
   truly common set.) Negotiation allows early adopters to start using
   PQ CAs where they can, while still remaining compatible with the
   root programs that support PQ but not yet with their chosen CAs.
   Without this, everyone must delay until things settle.


The approach you outline is to basically make easier for slower moving 
CAs to transition to PQ. Is this desirable? Aren't users better off in a 
world where CAs are racing to be the first to deploy PQ and enjoy 
widespread trust from root programs? Without there being any direct 
benefit to being early in the PQ transition, we're likely to see CAs 
reluctant to make the considerable investment in the necessary hardware, 
software and procedures. After all, why not let someone else go first 
and pave the way?


We'll also want to consider much shorter lifetimes for PQ root 
certificates to ensure that there cannot be a repeat of the Android 
debacle. I understand the Google Root Program has already announced an 
intent to limit root certificates to 7 year lifetimes [5]. This would 
effectively shift responsibility for handling old insecure devices from 
website operators to device manufacturers, where it correctly belongs.


Compared to the alternatives, Trust Expressions seems to solve the 
problems less effectively and introduce much greater risks. If you 
really feel the opposite is true, I would strongly encourage you to:
a) Write up concrete security benefits which Trust Expressions uniquely 
enables. It's important to explain not just how Trust Expressions solves 
the problem, but also why incentives are aligned for the various 
stakeholders to deploy it correctly such that those benefits can be 
realized.


b) Make a good faith attempt to engage with the concerns raised about 
the risks. Think through how a party with different goals to your own 
could exploit the negotiation offered by Trust Expressions for their own 
purposes. If your goal was instead to enable surveillance and domestic 
control of the web for your government, how would widespread support for 
Trust Expressions help you?


Best,
Dennis

[1] https://letsencrypt.org/images/isrg-hierarchy.png

[2] http://github.com/tlswg/draft-ietf-tls-cert-abridge/

[3] https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted

[4] 
https://www.ssl.com/blogs/ssl-com-legacy-cross-signed-root-certificate-expiring-on-september-11-2023/


[5] 
https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/#encouraging-modern-infrastructures-and-agility
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[marxmail] The ‘NYTimes’ finally publishes a comprehensive indictment of ‘Jewish terrorism’ against Palestinians

[Dennis Brasky]

The New York Times has astonished its readers by publishing a long
indictment of a subject it has purposely ignored for years: “Jewish
terrorism” against Palestinians.

https://mondoweiss.net/2024/05/the-nytimes-finally-publishes-a-comprehensive-indictment-of-jewish-terrorism-against-palestinians/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30421): https://groups.io/g/marxmail/message/30421
Mute This Topic: https://groups.io/mt/106203761/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[marxmail] Israeli rights group admits it helped spread false claims about 7 Oct. rapes

[Dennis Brasky]

Mark Twain - "A lie can make its way halfway around the world before the
truth gets its shoes on!" But we must make sure that the truth wins in the
end!

https://electronicintifada.net/blogs/ali-abunimah/israeli-rights-group-admits-it-helped-spread-false-claims-about-7-oct-rapes


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#30410): https://groups.io/g/marxmail/message/30410
Mute This Topic: https://groups.io/mt/106190432/21656
-=-=-
POSTING RULES & NOTES
#1 YOU MUST clip all extraneous text when replying to a message.
#2 This mail-list, like most, is publicly & permanently archived.
#3 Subscribe and post under an alias if #2 is a concern.
#4 Do not exceed five posts a day.
-=-=-
Group Owner: marxmail+ow...@groups.io
Unsubscribe: https://groups.io/g/marxmail/leave/8674936/21656/1316126222/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [FFmpeg-devel] [PATCH] lavd/v4l2: Use proper field type for second parameter of ioctl() with BSD's

[Dennis Mungai]

On Sat, 18 May 2024, 14:27 Brad Smith, 
wrote:

> Can this be backported to 7, 6, 5 and 4.4 releases?
>
> On 2024-05-05 11:59 p.m., Brad Smith wrote:
> > lavd/v4l2: Use proper field type for second parameter of ioctl() with
> BSD's
> >
> > The proper type was used until 73251678c83cbe24d08264da693411b166239bc7.
> >
> > This covers all of the OS's that currently have V4L2 support,
> permutations
> > of Linux glibc/musl, Android bionic, FreeBSD, NetBSD, OpenBSD, Solaris.
> >
> > Copied from FreeBSD ports patch.
> >
> > Signed-off-by: Brad Smith 
> > ---
> >   libavdevice/v4l2.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> > index 3706582bc6..74f43ef6a9 100644
> > --- a/libavdevice/v4l2.c
> > +++ b/libavdevice/v4l2.c
> > @@ -108,10 +108,10 @@ struct video_data {
> >   int (*open_f)(const char *file, int oflag, ...);
> >   int (*close_f)(int fd);
> >   int (*dup_f)(int fd);
> > -#ifdef __GLIBC__
> > -int (*ioctl_f)(int fd, unsigned long int request, ...);
> > -#else
> > +#if defined(__sun) || defined(__BIONIC__) || defined(__musl__) /*
> POSIX-like */
> >   int (*ioctl_f)(int fd, int request, ...);
> > +#else
> > +int (*ioctl_f)(int fd, unsigned long int request, ...);
> >   #endif
> >   ssize_t (*read_f)(int fd, void *buffer, size_t n);
> >   void *(*mmap_f)(void *start, size_t length, int prot, int flags,
> int fd, int64_t offset);
> _".
>


Seconded, a backport would be ideal for prior releases.

>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".