Connection errors in Asia Pacific region on July 9, 2023

Post Syndicated from Christian Elmerot original http://blog.cloudflare.com/connection-errors-in-asia-pacific-region-on-july-9-2023/

Connection errors in Asia Pacific region on July 9, 2023

Connection errors in Asia Pacific region on July 9, 2023

On Sunday, July 9, 2023, early morning UTC time, we observed a high number of DNS resolution failures — up to 7% of all DNS queries across the Asia Pacific region — caused by invalid DNSSEC signatures from Verisign .com and .net Top Level Domain (TLD) nameservers. This resulted in connection errors for visitors of Internet properties on Cloudflare in the region.

The local instances of Verisign’s nameservers started to respond with expired DNSSEC signatures in the Asia Pacific region. In order to remediate the impact, we have rerouted upstream DNS queries towards Verisign to locations on the US west coast which are returning valid signatures.

We have already reached out to Verisign to get more information on the root cause. Until their issues have been resolved, we will keep our DNS traffic to .com and .net TLD nameservers rerouted, which might cause slightly increased latency for the first visitor to domains under .com and .net in the region.

Background

In order to proxy a domain’s traffic through Cloudflare’s network, there are two components involved with respect to the Domain Name System (DNS) from the perspective of a Cloudflare data center: external DNS resolution, and upstream or origin DNS resolution.

To understand this, let’s look at the domain name blog.cloudflare.com — which is proxied through Cloudflare’s network — and let’s assume it is configured to use origin.example as the origin server:

Connection errors in Asia Pacific region on July 9, 2023

Here, the external DNS resolution is the part where DNS queries to blog.cloudflare.com sent by public resolvers like 1.1.1.1 or 8.8.8.8 on behalf of a visitor return a set of Cloudflare Anycast IP addresses. This ensures that the visitor’s browser knows where to send an HTTPS request to load the website. Under the hood your browser performs a DNS query that looks something like this (the trailing dot indicates the DNS root zone):

$ dig blog.cloudflare.com. +short
104.18.28.7
104.18.29.7

(Your computer doesn’t actually use the dig command internally; we’ve used it to illustrate the process) Then when the next closest Cloudflare data center receives the HTTPS request for blog.cloudflare.com, it needs to fetch the content from the origin server (assuming it is not cached).

There are two ways Cloudflare can reach the origin server. If the DNS settings in Cloudflare contain IP addresses then we can connect directly to the origin. In some cases, our customers use a CNAME which means Cloudflare has to perform another DNS query to get the IP addresses associated with the CNAME. In the example above, blog.cloudflare.com has a CNAME record instructing us to look at origin.example for IP addresses. During the incident, only customers with CNAME records like this going to .com and .net domain names may have been affected.

The domain origin.example needs to be resolved by Cloudflare as part of the upstream or origin DNS resolution. This time, the Cloudflare data center needs to perform an outbound DNS query that looks like this:

$ dig origin.example. +short
192.0.2.1

DNS is a hierarchical protocol, so the recursive DNS resolver, which usually handles DNS resolution for whoever wants to resolve a domain name, needs to talk to several involved nameservers until it finally gets an answer from the authoritative nameservers of the domain (assuming no DNS responses are cached). This is the same process during the external DNS resolution and the origin DNS resolution. Here is an example for the origin DNS resolution:

Connection errors in Asia Pacific region on July 9, 2023

Inherently, DNS is a public system that was initially published without any means to validate the integrity of the DNS traffic. So in order to prevent someone from spoofing DNS responses, DNS Security Extensions (DNSSEC) were introduced as a means to authenticate that DNS responses really come from who they claim to come from. This is achieved by generating cryptographic signatures alongside existing DNS records like A, AAAA, MX, CNAME, etc. By validating a DNS record’s associated signature, it is possible to verify that a requested DNS record really comes from its authoritative nameserver and wasn’t altered en-route. If a signature cannot be validated successfully, recursive resolvers usually return an error indicating the invalid signature. This is exactly what happened on Sunday.

Incident timeline and impact

On Saturday, July 8, 2023, at 21:10 UTC our logs show the first instances of DNSSEC validation errors that happened during upstream DNS resolution from multiple Cloudflare data centers in the Asia Pacific region. It appeared DNS responses from the TLD nameservers of .com and .net of the type NSEC3 (a DNSSEC mechanism to prove non-existing DNS records) did not include signatures. About an hour later at 22:16 UTC, the first internal alerts went off (since it required issues to be consistent over a certain period of time), but error rates were still at a level at around 0.5% of all upstream DNS queries.

After several hours, the error rate had increased to a point in which ~13% of our upstream DNS queries in affected locations were failing. This percentage continued to fluctuate over the duration of the incident between the ranges of 10-15% of upstream DNS queries, and roughly 5-7% of all DNS queries (external & upstream resolution) to affected Cloudflare data centers in the Asia Pacific region.

Connection errors in Asia Pacific region on July 9, 2023

Initially it appeared as though only a single upstream nameserver was having issues with DNS resolution, however upon further investigation it was discovered that the issue was more widespread. Ultimately, we were able to verify that the Verisign nameservers for .com and .net were returning expired DNSSEC signatures on a portion of DNS queries in the Asia Pacific region. Based on our tests, other nameserver locations were correctly returning valid DNSSEC signatures.

In response, we rerouted our DNS traffic to the .com and .net TLD nameserver IP addresses to Verisign’s US west locations. After this change was propagated, the issue very quickly subsided and origin resolution error rates returned to normal levels.

All times are in UTC:

2023-07-08 21:10 First instances of DNSSEC validation errors appear in our logs for origin DNS resolution.

2023-07-08 22:16 First internal alerts for Asia Pacific data centers go off indicating origin DNS resolution error on our test domain. Very few errors for other domains at this point.

2023-07-09 02:58 Error rates have increased substantially since the first instance. An incident is declared.

2023-07-09 03:28 DNSSEC validation issues seem to be isolated to a single upstream provider. It is not abnormal that a single upstream has issues that propagate back to us, and in this case our logs were predominantly showing errors from domains that resolve to this specific upstream.

2023-07-09 04:52 We realize that DNSSEC validation issues are more widespread and affect multiple .com and .net domains. Validation issues continue to be isolated to the Asia Pacific region only, and appear to be intermittent.

2023-07-09 05:15 DNS queries via popular recursive resolvers like 8.8.8.8 and 1.1.1.1 do not return invalid DNSSEC signatures at this point. DNS queries using the local stub resolver continue to return DNSSEC errors.

2023-07-09 06:24 Responses from .com and .net Verisign nameservers in Singapore contain expired DNSSEC signatures, but responses from Verisign TLD nameservers in other locations are fine.

2023-07-09 06:41 We contact Verisign and notify them about expired DNSSEC signatures.

2023-07-09 06:50 In order to remediate the impact, we reroute DNS traffic via IPv4 for the .com and .net Verisign nameserver IPs to US west IPs instead. This immediately leads to a substantial drop in the error rate.

2023-07-09 07:06 We also reroute DNS traffic via IPv6 for the .com and .net Verisign nameserver IPs to US west IPs. This leads to the error rate going down to zero.

2023-07-10 09:23 The rerouting is still in place, but the underlying issue with expired signatures in the Asia Pacific region has still not been resolved.

2023-07-10 18:23 Versign gets back to us confirming that they “were serving stale data” at their local site and have resolved the issues.

Technical description of the error and how it happened

As mentioned in the introduction, the underlying cause for this incident was expired DNSSEC signatures for .net and .com zones. Expired DNSSEC signatures will cause a DNS response to be interpreted as invalid. There are two main scenarios in which this error was observed by a user:

  1. CNAME flattening for external DNS resolution. This is when our authoritative nameservers attempt to return the IP address(es) that a CNAME record target resolves to rather than the CNAME record itself.
  2. CNAME target lookup for origin DNS resolution. This is most commonly used when an HTTPS request is sent to a Cloudflare anycast IP address, and we need to determine what IP address to forward the request to. See How Cloudflare works for more details.

In both cases, behind the scenes the DNS query goes through an in-house recursive DNS resolver in order to lookup what a hostname resolves to. The purpose of this resolver is to cache queries, optimize future queries and provide DNSSEC validation. If the query from this resolver fails for whatever reason, our authoritative DNS system will not be able to perform the two scenarios outlined above.

Connection errors in Asia Pacific region on July 9, 2023

During the incident, the recursive resolver was failing to validate the DNSSEC signatures in DNS responses for domains ending in .com and .net. These signatures are sent in the form of an RRSIG record alongside the other DNS records they cover. Together they form a Resource Record set (RRset). Each RRSIG has the corresponding fields:

Connection errors in Asia Pacific region on July 9, 2023

As you can see, the main part of the payload is associated with the signature and its corresponding metadata. Each recursive resolver is responsible for not only checking the signature but also the expiration time of the signature. It is important to obey the expiration time in order to avoid returning responses for RRsets that have been signed by old keys, which could have potentially been compromised by that time.

During this incident, Verisign, the authoritative operator for the .com and .net TLD zones, was occasionally returning expired signatures in its DNS responses in the Asia Pacific region. As a result our recursive resolver was not able to validate the corresponding RRset. Ultimately this meant that a percentage of DNS queries would return SERVFAIL as response code to our authoritative nameserver. This in turn caused connection issues for users trying to connect to a domain on Cloudflare, because we weren't able to resolve the upstream target of affected domain names and thus didn’t know where to send proxied HTTPS requests to upstream servers.

Remediation and follow-up steps

Once we had identified the root cause we started to look at different ways to remedy the issue. We came to the conclusion that the fastest way to work around this very regionalized issue was to stop using the local route to Verisign's nameservers. This means that, at the time of writing this, our outgoing DNS traffic towards Verisign's nameservers in the Asia Pacific region now traverses the Pacific and ends up at the US west coast, rather than being served by closer nameservers. Due to the nature of DNS and the important role of DNS caching, this has less impact than you might initially expect. Frequently looked up names will be cached after the first request, and this only needs to happen once per data center, as we share and pool the local DNS recursor caches to maximize their efficiency.

Ideally, we would have been able to fix the issue right away as it potentially affected others in the region too, not just our customers. We will therefore work diligently to improve our incident communications channels with other providers in order to ensure that the DNS ecosystem remains robust against issues such as this. Being able to quickly get hold of other providers that can take action is vital when urgent issues like these arise.

Conclusion

This incident once again shows how impactful DNS failures are and how crucial this technology is for the Internet. We will investigate how we can improve our systems to detect and resolve issues like this more efficiently and quickly if they occur again in the future.

While Cloudflare was not the cause of this issue, and we are certain that we were not the only ones affected by this, we are still sorry for the disruption to our customers and to all the users who were unable to access Internet properties during this incident.

Всичко в една длан – истории за оцеляване и уроци по живеене

Post Syndicated from Таня Иванова original https://www.toest.bg/vsichko-v-edna-dlan-istorii-za-otselyavane-i-urotsi-po-zhiveene/

Всичко в една длан – истории за оцеляване и уроци по живеене

В разгара на пандемията през 2020 г., когато светът четеше с такава жажда, сякаш в книгите щеше да открие всички отговори за неизвестното, пред което бяхме изправени, трудно успявах да се концентрирам върху цяла страница. Започвах книга след книга в опит поне една да задържи вниманието ми, но без успех. Наблюдавах с почуда и дори с лека завист снимки в социалните медии на планини от прочетени книги и на благодарни хора, че в тези страшни дни се е отворило време за четене. Винаги съм била четящ човек и често се шегувах, че ако не бях се захванала с музика, щях да се занимавам с литература.

Но сега нещо не беше наред с мен, усещах го инстинктивно.

Един ден попаднах на публикация в сайта на Vogue, в който авторката открито споделяше, че от началото на пандемията е загубила спокойствието си за четене. Напълно непознат човек в другия край на света беше описал това, през което аз самата преминавах. Облекчението от усещането, че не съм сама, дойде мигновено. Затова няколко дни по-късно, когато прочетох друг материал, разказващ за нов проект, чиято идея беше чрез творчество и кратки есета да ни помогне срещу самотата по време на изолация, да ни свърже и да ни направи по-малко безпомощни пред лицето на пандемията,

веднага се абонирах за The Isolation Journals. Така научих за Сулейка Джауад.

Родена в Ню Йорк в семейството на родители от Швейцария и Тунис, Сулейка отраства с три паспорта и владее три езика. През 2011 г. завършва образованието си и се премества да живее в Париж, където започва първата си работа. Мечтата ѝ по онова време е да стане военна кореспондентка, но нейната лична история я изправя пред не по-малко сериозен конфликт – битката между живота и смъртта.

Скоро след установяването си във Франция е диагностицирана с левкемия. Според лекарите шансовете ѝ за оцеляване не надхвърлят обезкуражаващите 35%. В следващите четири години болницата се превръща в дом за Сулейка, която започва да пише блог от болничното си легло. Той прераства в рубриката Life, Interrupted (Живот на пауза) и намира читатели по цял свят.

Неотдавна любим човек ми изпрати мъдрост от духовния учител Рам Дас. „Каква е разликата между затвора и манастира?“ — пита той. Отговорът: „Почти няма такава. И двете места са пълни с хора, които по цял ден са сами в килиите си, далеч от света. Разликата е, че за монасите това е раят, а за затворниците – адът.“ Тези думи резонират в мен тук, в болничната ми стая, която намирам за странна смесица от двете. От опит научих подразбиращия се урок на Дас, че е възможно тази клетка да се превърне в светилище на размисъла и самотата. И как го постигам? Като се оглеждам не с очите на някой, който е изправен пред смъртта, а с очите на новородена. Трябва да се удивлявам на този малък, често мрачен свят, да гледам дори на най-дребните детайли като на нещо интересно по своята същност – като на нещо красиво, абсурдно или дори изключително смешно.

В нашето общество обикновено на оцелелите след подобен травматичен опит се гледа като на истински герои. Не така възприема себе си Сулейка Джауад, когато излиза от болницата. По време на участието си в TED Talks през 2019 г. тя разказва, че се е сблъскала с най-голямото предизвикателство не докато е била в затвореното и защитено болнично пространство, а след това, когато е трябвало да се завърне към нормалния си начин на живот.

Сулейка си спомня момента, в който се озовава в празния си апартамент съвсем сама, тъй като дългогодишният ѝ приятел си е тръгнал, а най-добрата ѝ приятелка, на която е искала да се обади и да сподели всичко с нея, е починала от рак три седмици по-рано. Така започва изпитанието на Сулейка да се научи да живее отново. Това е периодът, в който се налага, от една страна, да приеме промените в тялото си след химиотерапията, а от друга, промените в психиката си – да открие начин да се пребори със „страха от рецидив, с непреработената тъга и демоните на посттравматичното разстройство“.

Дни като тези могат да ме изстрелят в обсесивно размишление. Събуждам се посред нощ, мислейки за трансплантацията и какво означава тя на всяко ниво: за тялото ми, семейството ми, работата ми, връзката ми, за всичките ми планове.

Днес беше първият ден, в който се събудих без болка. Докато слизах по стълбите, не трябваше да се подпирам на парапета. Можех да ходя почти нормално. Улових се да казвам: „Благодаря ви, крака!“ Това, което изпитвах към тях, граничеше с благоговение.

Следват дни, в които Сулейка се събужда толкова тъжна и изгубена, че едва успява да си поеме дъх, но погледнато в по-общ план, самотата ѝ е само привидна. Заради рубриката си в New York Times тя е получила уважение и съчувствие под формата на стотици писма от читатели. Пишат ѝ хора, които се опитват да я окуражат, като някои от тях споделят не по-малко драматичните си лични истории. Размишлявайки върху прочетеното, Сулейка решава, че има нужда от промяна. Заедно с кучето Оскар, проклетник по характер, но верен и любящ неин приятел, потеглят на пътешествие, изминавайки над 24 000 км из САЩ. Това е време за близки срещи със страданието на другите, за вникване в чудото на живота и раждането на нови мечти.

Това не е някакъв опростен отговор на идеята „променете мисленето си, променете живота си“. Не мога да се откажа от моята телесна реалност. Нямам духовните мускули да се издигна над физическия дискомфорт. Така че трябва да се науча да живея и с двете: да изпитвам силна болка и в същото време да намеря малко отдих. Копнея за мечтателни, поетични моменти на вдъхновение и полагам много усилия за да ги търся навсякъде, където мога. Хубавото е, че когато започна да ги търся, ги намирам по-често. Усещам ги по-често.

С настъпването на пандемията през 2020 г. Сулейка, която заради боледуването си има непосредствен опит с изолацията, решава да създаде бюлетин, обединявайки различни хора по света, които имат нужда да се подкрепят взаимно и които чрез творчески занимания повдигат духа си. Така се ражда идеята за The Isolation Journals (Дневници на изолацията). Регулярно, през няколко дни, Сулейка Джауад изпраща на абониралите се писма, в които разказва за моменти от живота си, придружени от кратки текстове на други автори, техни думи, които по някакъв начин са я докоснали и утешили. Сулейка провокира своите читатели с проекти като 30-дневно водене на дневник или 100-дневно творческо предизвикателство, в което чрез изкуството изразяваш себе си – непреднамерено и с любопитство към света.

Това беше привидно безкраен сезон на трудности и несигурност за всички и въпреки това, както винаги става, в него имаше и толкова много красиви и радостни моменти. Воденето на дневник е начинът, по който разбирам тези противоречия и безбройните неясноти в живота. Това е начинът, по който разбирам света и мястото си в него, така се уча да приемам всичко – както трудните неща, така и удивителните.

През последното десетилетие писах много за връзката между творчеството и болестта – как ограниченията налагат изобретателност, как сблъсъкът с тленността ви принуждава да намерите нови начини за изразяване, как прекъсванията в живота изместват ума ви от нормалния му коловоз.

Броят на абониралите се за The Isolation Journals непрекъснато се увеличава.

Бюлетинът прераства в общност, която към днешна дата наброява над 100 000 души, а изкуството се превръща в котва за тази общност.

За да поддържа непосредствена връзка със своите последователи, Сулейка създава и рубриката Dear Susu, в която дава съвети, отговаряйки на читателски писма.

Това е толкова красиво – този копнеж за връзка, това желание да видиш, да бъдеш видян, да разбереш, да бъдеш разбран. И не мисля, че някъде другаде извън тази общност съм забелязвала толкова силно проявление. Удивително е – всяко обаждане получава отговор, всяко ехо отеква още повече. Има сила в сбора от всички тези гласове. В тази връзка ние надграждаме историята на човешкия опит, която надхвърля конкретното и става универсална.

През 2021 г. Сулейка Джауад издава мемоарите си „Между две кралства“ (Between Two Kingdoms), в които разказва за своята диагноза, лечение и възстановяване. Заглавието е препратка към книгата на Сюзан Зонтаг „Болестта като метафора“ (Illness as Metaphor), в която американската писателка посочва, че с раждането си всеки един от нас получава двойно гражданство – в кралството на здравето и кралството на болестта. Книгата на Джауад се превръща в бестселър на New York Times и още повече разширява кръга на нейните читатели.

Това сякаш е особено плодотворен период за Сулейка – тя вече е успяла да утвърди името си като писателка и мотивационна ораторка, срещнала е голямата любов и се занимава с това, което истински обича. За нейно огромно съжаление няколко месеца по-късно животът я изправя пред ново предизвикателство. Сулейка се разболява отново – този път ракът се завръща в още по-агресивна форма.

Усещането е много странно, след като толкова неща се промениха през последните седем години. Връщайки се назад, мога да кажа, че имах безкрайни копнежи: да намеря любовта, да имам собствен дом, да напиша книга, да направя кариера. Като по чудо всичко това ми се случи, но аз продължавам да имам своите копнежи. Сега е различно, тъй като не копнея за конкретни неща, а жадувам за думата „повече“. Това е горчивата сладост да бъдат изпълнени желанията ти, а след това да си изправен пред перспективата да загубиш всичко, което имаш. Обичам си живота, обичам си семейството, съпруга ми, сладкото ми ново куче, обичам приятелите си, моя дом, градината ми, моята работа и любимата общност тук и искам да мога да се наслаждавам на този живот днес и утре, и за много години напред.

През февруари миналата година Сулейка отново се подлага на трансплантация на костен мозък. Неин донор за втори път е брат ѝ Адам. В следващите месеци тя ще трябва многократно да се справя с усложнения след трансплантацията, а преживяването ще бъде болезнен тест за несломимостта на човешкия дух и челен сблъсък с уязвимостта на тялото. През този период Сулейка ще продължи да поддържа връзка със своята общност в The Isolation Journals и ще се опитва да преобразува опита си в творческо гориво, а изолацията – в творческа самота.

В бюлетина си Сулейка ще публикува свои снимки от болницата, на които рисува причудливите си акварели. В картините ѝ оживяват странни, сюрреалистични същества, родени от несъзнаваното, но притежаващи силата да озаряват. Сулейка разкрива, че обича тези акварели заради загадъчната неизвестност, предшестваща появата на образа, както и заради тишината и уединението, които съпътстват тяхното създаване.

Писането и рисуването не изтриват страховете ми – те не изчезват напълно, но трансформирането им в думи и акварели ми позволява да ги изследвам и да имам контрол над тях. Така се превръщам в манипулатор на страховете си, а не аз съм тази, която е манипулирана. Това казах на една скъпа приятелка по-късно същата сутрин. Неин близък е болен и те чакаха резултати от тестове, а ние изразихме съчувствие колко е мъчително чакането. „Надявам се, че ще имате възможност да напишете няколко страници сутринта или може би дори да порисувате – казах аз. – Това не премахва ужаса, но променя формата му.“

Най-поразителното в бюлетина на Сулейка Джауад е езикът, на който тя разказва за ежедневието си. Много от нас биха се затруднили да говорят с такава приобщаваща лекота и естественост отвъд обичайните клишета или отвъд страха да опишем ужаса с думи. Сулейка е намерила начин да помири крайностите, или както често обича да казва,

за нея голяма част от живота е свързана с това да държи в една и съща длан едновременно както красивите неща, така и най-жестоките, най-трудните за преживяване.

В текстовете си тя разграничава празнуването на малките радости в живота от тиранията на „токсичната позитивност“. Хората, които боледуват, често изпитват дълбока духовна умора от необходимостта да се чувстват благодарни и от натиска да откриват положителното във всеки един момент. Според нея нито тъгата, нито дискомфортът са нещо толкова лошо, колкото е възприето в съвременната култура. Нейният подход е да интегрира тъгата в своя опит, поемайки по пътя на трансформацията.

Междувременно ето някои напомняния: бъдете търпеливи и нежни. Не се укорявайте за липсата на енергия, не се осъждайте за начина, по който изглеждате, не се фокусирайте върху това, което пропускате. Вярвайте, че нещо се случва, че вашите молекули се разместват и пренареждат. Вярвайте, че се променяте, че се лекувате, защото, ако съм научила нещо, то е, че лечението много рядко изглежда така, както си мислите.

Ето какво мога да кажа за процеса на лечение: вършите невъзможната работа да погледнете назад и да сглобите парчетата от случилото се, като същевременно трябва да сте потопени в момента и да насочвате погледа си към предстоящия обнадеждаващ път. Това едновременно притегляне на минало, настояще и бъдеще е като да попаднеш в кръгово движение. Толкова е шеметно – как, за бога, можеш да направиш стабилна крачка?

Но грешах за едно нещо – че няма да се справя. Можех да се справя и се справих. Всеки път се изненадвам как се страхуваш от нещо и си мислиш, че не можеш да го понесеш. Но когато това, от което се страхувате, се случи, вие разкривате нови запаси от сила, за които дори не сте подозирали.

Любовта е сред най-мощните генератори на сила. Доказва го и случаят със Сулейка Джауад. Неин партньор в живота е един от съвременните музикални гении. Джон Батист е пианист, вокалист, композитор и музикален директор на Шоуто на Стив Колбърт, носител на някои от най-престижните награди в света – „Оскар“, „Златен глобус“ и „Грами“. Сулейка определя своя любим като един от най-забавните и най-мили хора, които познава, и като най-трудолюбивия и брилянтен човек в творческо отношение.

Джон е плътно до Сулейка в нейната нова битка за оцеляване. В най-трудните ѝ моменти, когато тя се бори с безсънието в болничното си легло, той създава приспивни песни специално за нея, за да я утеши и да ѝ помогне да се отпусне. В едно интервю Батист разкрива, че музиката е неговият начин да допринесе за процеса на оздравяване. През април миналата година, когато изписват Сулейка от болницата, двамата с Джон Батист предприемат следващата стъпка в своите взаимоотношения – заживяват заедно.

Процесът на подготовка за преместване в този дом беше истинска радост за мен. Винаги съм била домошарка, но в този период на боледуване изпитвам толкова дълбока, почти първична нужда да създам гнездо, където мога да си почина и да се излекувам. Открих, че влагам мисъл и грижа във всеки детайл, както никога досега. Търсенето на малки красиви предмети е добре дошло разсейване от трудностите и всеки път, когато открия перфектната подложка за сапун или ретро кана за вода, това оказва огромен ефект върху мен.

В ежедневието на Сулейка се преплитат различни реалности, това е и подканата към нея да побере в дланта си крайностите на живота. Тя е особено развълнувана и горда, когато през февруари миналата година Джон Батист получава 11 номинации за „Грами“ за новата си продукция We Are. Впоследствие печели в пет от категориите, включително и за „Албум на годината“.

Пак през февруари, докато Сулейка се подготвя за трансплантацията на костен мозък, двамата с Джон Батист решават да се оженят тайно. Когато по-късно в репортаж на CBS Sunday Morning те разказват за първи път публично за своя брак, журналистът Джим Акселрод определя тази стъпка като проява на оптимизъм и заявка за това, че имат бъдеще. В коментара на Джон Батист за станалото се прокрадва още един нюанс – за него този брак е открито неподчинение на ситуацията, в която се намират двамата със Сулейка. „В тези моменти тъмнината се опитва да те превземе, но просто се фокусирай върху светлината, дръж се за нея“ – отвръща Батист.

Днес Сулейка е преодоляла левкемията, но лечението ще продължи под някаква форма до края на живота ѝ. Докато пиша тези редове, тримата с Джон Батист и очарователното куче асистент Ривър са на пътешествие във Франция и според снимките, публикувани в социалните медии, се наслаждават на времето си заедно.

Този път преживяването е толкова различно. Не копнея за постижения – професионални или други. Не си мисля: „О, просто искам да напиша още една книга, да се срещна с нови хора, да видя повече неща.“ Всичко, което искам, е време. Искам да се обърна назад към годината и да си спомня всички дни с неясни очертания, в които не гледах в телефона си, не работех, в които бях истински заедно с приятелите и семейството си. Искам да си спомня за часовете, които прекарах в рисуване на тези странни, някак тъмни, но изпълнени предимно с радост и любов картини. Искам да си спомня за времето, прекарано в моята градина, която миналата зима беше засадена със стотици луковици и ще цъфти през пролетта. Каквото и да оставя след себе си, искам да изразява уважение към времето.


Всички цитати, които не са посочени изрично, са от текстове на Сулейка Джауад за бюлетина The Isolation Journals.

Roots of Trust are difficult

Post Syndicated from original https://mjg59.dreamwidth.org/66907.html

The phrase “Root of Trust” turns up at various points in discussions about verified boot and measured boot, and to a first approximation nobody is able to give you a coherent explanation of what it means[1]. The Trusted Computing Group has a fairly wordy definition, but (a) it’s a lot of words and (b) I don’t like it, so instead I’m going to start by defining a root of trust as “A thing that has to be trustworthy for anything else on your computer to be trustworthy”.

(An aside: when I say “trustworthy”, it is very easy to interpret this in a cynical manner and assume that “trust” means “trusted by someone I do not necessarily trust to act in my best interest”. I want to be absolutely clear that when I say “trustworthy” I mean “trusted by the owner of the computer”, and that as far as I’m concerned selling devices that do not allow the owner to define what’s trusted is an extremely bad thing in the general case)

Let’s take an example. In verified boot, a cryptographic signature of a component is verified before it’s allowed to boot. A straightforward implementation of a verified boot implementation has the firmware verify the signature on the bootloader or kernel before executing it. In this scenario, the firmware is the root of trust – it’s the first thing that makes a determination about whether something should be allowed to run or not[2]. As long as the firmware behaves correctly, and as long as there aren’t any vulnerabilities in our boot chain, we know that we booted an OS that was signed with a key we trust.

But what guarantees that the firmware behaves correctly? What if someone replaces our firmware with firmware that trusts different keys, or hot-patches the OS as it’s booting it? We can’t just ask the firmware whether it’s trustworthy – trustworthy firmware will say yes, but the thing about malicious firmware is that it can just lie to us (either directly, or by modifying the OS components it boots to lie instead). This is probably not sufficiently trustworthy!

Ok, so let’s have the firmware be verified before it’s executed. On Intel this is “Boot Guard”, on AMD this is “Platform Secure Boot”, everywhere else it’s just “Secure Boot”. Code on the CPU (either in ROM or signed with a key controlled by the CPU vendor) verifies the firmware[3] before executing it. Now the CPU itself is the root of trust, and, well, that seems reasonable – we have to place trust in the CPU, otherwise we can’t actually do computing. We can now say with a reasonable degree of confidence (again, in the absence of vulnerabilities) that we booted an OS that we trusted. Hurrah!

Except. How do we know that the CPU actually did that verification? CPUs are generally manufactured without verification being enabled – different system vendors use different signing keys, so those keys can’t be installed in the CPU at CPU manufacture time, and vendors need to do code development without signing everything so you can’t require that keys be installed before a CPU will work. So, out of the box, a new CPU will boot anything without doing verification[4], and development units will frequently have no verification.

As a device owner, how do you tell whether or not your CPU has this verification enabled? Well, you could ask the CPU, but if you’re doing that on a device that booted a compromised OS then maybe it’s just hotpatching your OS so when you do that you just get RET_TRUST_ME_BRO even if the CPU is desperately waving its arms around trying to warn you it’s a trap. This is, unfortunately, a problem that’s basically impossible to solve using verified boot alone – if any component in the chain fails to enforce verification, the trust you’re placing in the chain is misplaced and you are going to have a bad day.

So how do we solve it? The answer is that we can’t simply ask the OS, we need a mechanism to query the root of trust itself. There’s a few ways to do that, but fundamentally they depend on the ability of the root of trust to provide proof of what happened. This requires that the root of trust be able to sign (or cause to be signed) an “attestation” of the system state, a cryptographically verifiable representation of the security-critical configuration and code. The most common form of this is called “measured boot” or “trusted boot”, and involves generating a “measurement” of each boot component or configuration (generally a cryptographic hash of it), and storing that measurement somewhere. The important thing is that it must not be possible for the running OS (or any pre-OS component) to arbitrarily modify these measurements, since otherwise a compromised environment could simply go back and rewrite history. One frequently used solution to this is to segregate the storage of the measurements (and the attestation of them) into a separate hardware component that can’t be directly manipulated by the OS, such as a Trusted Platform Module. Each part of the boot chain measures relevant security configuration and the next component before executing it and sends that measurement to the TPM, and later the TPM can provide a signed attestation of the measurements it was given. So, an SoC that implements verified boot should create a measurement telling us whether verification is enabled – and, critically, should also create a measurement if it isn’t. This is important because failing to measure the disabled state leaves us with the same problem as before; someone can replace the mutable firmware code with code that creates a fake measurement asserting that verified boot was enabled, and if we trust that we’re going to have a bad time.

(Of course, simply measuring the fact that verified boot was enabled isn’t enough – what if someone replaces the CPU with one that has verified boot enabled, but trusts keys under their control? We also need to measure the keys that were used in order to ensure that the device trusted only the keys we expected, otherwise again we’re going to have a bad time)

So, an effective root of trust needs to:

1) Create a measurement of its verified boot policy before running any mutable code
2) Include the trusted signing key in that measurement
3) Actually perform that verification before executing any mutable code

and from then on we’re in the hands of the verified code actually being trustworthy, and it’s probably written in C so that’s almost certainly false, but let’s not try to solve every problem today.

Does anything do this today? As far as I can tell, Intel’s Boot Guard implementation does. Based on publicly available documentation I can’t find any evidence that AMD’s Platform Secure Boot does (it does the verification, but it doesn’t measure the policy beforehand, so it seems spoofable), but I could be wrong there. I haven’t found any general purpose non-x86 parts that do, but this is in the realm of things that SoC vendors seem to believe is some sort of value-add that can only be documented under NDAs, so please do prove me wrong. And then there are add-on solutions like Titan, where we delegate the initial measurement and validation to a separate piece of hardware that measures the firmware as the CPU reads it, rather than requiring that the CPU do it.

But, overall, the situation isn’t great. On many platforms there’s simply no way to prove that you booted the code you expected to boot. People have designed elaborate security implementations that can be bypassed in a number of ways.

[1] In this respect it is extremely similar to “Zero Trust”
[2] This is a bit of an oversimplification – once we get into dynamic roots of trust like Intel’s TXT this story gets more complicated, but let’s stick to the simple case today
[3] I’m kind of using “firmware” in an x86ish manner here, so for embedded devices just think of “firmware” as “the first code executed out of flash and signed by someone other than the SoC vendor”
[4] In the Intel case this isn’t strictly true, since the keys are stored in the motherboard chipset rather than the CPU, and so taking a board with Boot Guard enabled and swapping out the CPU won’t disable Boot Guard because the CPU reads the configuration from the chipset. But many mobile Intel parts have the chipset in the same package as the CPU, so in theory swapping out that entire package would disable Boot Guard. I am not good enough at soldering to demonstrate that.

comment count unavailable comments

Градски мечти – между Андалусия и Пловдив

Post Syndicated from Георги Велев original https://www.toest.bg/gradski-mechti-mezhdu-andalusia-i-plovdiv/

Градски мечти – между Андалусия и Пловдив

В началото на май имах възможност да пътешествам из Андалусия – автономен регион в Южна Испания, световноизвестен с фламенкото, бикоборството, жаркото лято и неповторимата мавританска архитектура, едновременно повлияна от мюсюлманската традиция и християнския канон. Обикалях по тесните улички, носещи наследството на множество епохи – от Средновековие до неокласицизъм – и в продължение на часове не виждах други превозни средства освен велосипеди и електрически скутери.

В градове като Малага, Гранада и Севиля пешеходците осезаемо са поставени в центъра на урбанистичното планиране,

градският транспорт служи като ефективно допълнение за изминаване на по-дълги разстояния и резултатът е вдъхновяващ.

След като се върнах в Пловдив, контрастът беше особено силен и осъзнах, че през последните години придвижването се е превърнало в нетърпим проблем, включително и заради множеството недовършени ремонти на транспортната инфраструктура и липсата на адекватен обществен транспорт. Зададох си въпроса

къде се изгубиха вдъхновението и визията, съпътстващи подготовката и реализацията на проекта „Европейска столица на културата“?

Какво е необходимо на града, за да се върне към своите пешеходни корени, естествено заключен между древните хълмове и лениво течащата река? Може ли да почерпим идеи от други населени места, в които лятото продължава сякаш безкрайно, температурите достигат 40 градуса и хората търсят прохлада на сянка?

Пешеходци, счупени антипаркинг колчета и управленски непукизъм

В центъра на андалусийските градове хората могат да ползват както изцяло пешеходни зони, така и много улици, в които влизането с превозни средства (основно за зареждане на магазини и измиване на настилките) е разрешено само в ранните сутрешни часове, когато няма потоци от туристи.

Не по-малко важни са инициативи като тази на местната управа в Малага, която използва разширяването на метрото и през 2018–2019 г. трансформира булевард „Аламеда Принсипал“, водещ към историческата част, и отрежда 70% от пространството за пешеходци, портокалови дръвчета и маси на заведения. По този начин се създават условия за плавно преминаване от стандартни градоустройствени решения към пълното изключване на колите в един бъдещ момент.

Кметството в Гранада решава да отбележи Европейската седмица на мобилността през септември 2020 г., като въвежда приоритетен достъп за пешеходци по ул. „Сан Антон“ и някои от пресечките ѝ. Изготвени са карта и подробни указания как живеещите в района собственици на гаражи, пенсионери и хора с увреждания, а също и гости на хотели и доставчици на стоки могат да се сдобият с разрешение за достъп до улицата след подаване на електронно заявление. За останалите моторни превозни средства движението се измества по околните улички, като ясната цел е трафикът в района да бъде значително намален.

По време на мандата на бившия кмет Иван Тотев общинските власти в Пловдив многократно се хвалиха, че с реконструкцията на Главната е изградена най-дългата пешеходна улица в света, и още през 2017 г. се обмисляше вариант за удължаването ѝ по ул. „Иван Вазов“ в посока към Централната железопътна гара. Дали улица „Стрьогет“ в Копенхаген, която държеше тази неформална титла в продължение на години, е действително по-къса от „Княз Александър Първи“, има значение основно от маркетингова гледна точка, но неадекватната поддръжка на околните зони в идеалния център е ежедневен проблем.

След четири години демонстративен непукизъм по време на управлението на Здравко Димитров състоянието на „Капана“ и емблематични улици като „Отец Паисий“ прогресивно се влошава –

счупените антипаркинг колчета дават възможност за непозволено паркиране, ограниченият достъп в т.нар. зелена зона не съществува, а контролът от Общината е минимален.

Опитът на редица градове в Западна и Централна Европа доказва, че постепенното затваряне на нови улици за движение – както на споменатите „Иван Вазов“ и „Отец Паисий“, така и на традиционно търговската „Христо Г. Данов“ – може да доведе до множество позитиви. Подобни действия придобиват допълнителен смисъл, когато става въпрос за вариант, вече търсен от местните занаятчии.

През уикендите и празничните дни пешеходните пространства в центъра са недостатъчни и повече възможности за разходка без автомобили означава да се вдъхне живот в райони, където до момента хората не прекарват достатъчно време. Артериите, водещи към Главната, се нуждаят от засаждане на дървета, поставяне на пейки и изграждане на велоалеи, което няма как да стане, докато са запушени от стотици автомобили, търсещи паркоместа. Не е без значение и фактът, че центърът на Пловдив е визитната картичка на града, която се споделя от туристите, а пешеходните пространства позволяват по-пълноценно и автентично преживяване в сравнение със задръстените улици.

Съвсем отделен, но също толкова важен (и липсващ) е дебатът как да се създадат повече пешеходни зони в кварталите – например около Гребната база и ул. „Карловска“, така че да се обособят нови райони без автомобили съответно в западната и северната част на Пловдив.

Подлезите – антисоциалното наследство на комунизма

В централните зони на Малага, Гранада и Севиля не се натъкнах на нито един подлез. Испанските общини са защитили автентичния облик на населените места и не са се подвели по грешните тенденции от втората половина на XX век, когато се търсят начини за изместване на пешеходните трасета под земята, за да се ускори трафикът. Нещо повече, заради горещините се прилагат иновативни идеи за по-приятно прекарване на времето на открито – например чрез поставяне на платна между сградите в тесните улички, където няма възможност за засаждане на дървета, така че температурите да остават поносими през лятото.

Пловдивските подлези са известни с мръсотията, лошото осветление, честите вандалски прояви и некачествената поддръжка, която води до немалко инциденти.

През последното десетилетие управляващите не спират да обещават, че ще подобрят състоянието на тези съоръжения, но реалността си остава същата. Така се стигна до идеи като колосално скъпия проект за реновиране на подлеза на „Баня Старинна“, който се оценяваше на 3,2 млн. лв. още преди пандемията, инфлацията и значителното увеличение на цените на строителните материали.

Съвременните урбанистични концепции изцяло отричат подлезите като начин за преминаване на натоварени булеварди,

тъй като създават неудобства на пешеходците, ползването им с велосипеди е неприятно, а за майките с деца и хората с увреждания обикновено представляват непреодолими препятствия. Премахването на подземните връзки в централната градска част е стъпка, която ще доведе до значително улеснение за хиляди души всеки ден. За първи етап може да се избере един от главните булеварди, например „Шести септември“, „Христо Ботев“ или „Цар Борис III Обединител“.

Замяната на подлезите с пешеходни пътеки или изграждането на кръстовища със светофарни уредби ще увеличи достъпността, ще позволи свързване на изолирани велоалеи и би представлявало съществена помощ за непривилегированите групи. Може дори да помечтаем за своеобразно възстановяване на разкъсаната градска тъкан между Стария град и „Капана“ след построяването на тунела под Трихълмието, като липсващата улица се замени с повдигнато пешеходно пресичане.

Няма спор, че заместването на подлезите със светофари ще забави скоростта на трафика и ще причини неудобство на шофьорите, но градовете на XXI век се познават по това, че поставят хората, а не автомобилите в центъра на планирането.

Сахат тепе – забравеното съкровище

Историята на Пловдив е свързана неразривно с тепетата, чийто точен брой е обект на дългогодишни спорове, но за съжаление, към днешна дата са останали едва шест. На Небет тепе се изграждат последователно античен гарнизон и ранносредновековна крепост, а през Възраждането по склоновете му, както и по съседните Джамбаз тепе и Таксим тепе знатни търговци и занаятчии издигат внушителни къщи. Бунарджика е ценèн заради многобройните извори на прясна вода, а в съвремието предизвиква противоречия с Паметника на Съветската армия, известен още с името на изобразения войник Альоша.

За разлика от Стария град, който е задължителна част от туристическите маршрути и традиционно е домакин на редица фестивали, и Бунарджика, където се провеждат културни събития до възстановения през 2019 г. акведукт, Сахат тепе остава встрани от радара на множество пловдивчани и гости на града. Известно още с името Данов хълм в чест на известния книгоиздател, то е защитено като природна забележителност заради уникалната си геоморфология и ценни растителни и животински видове, а през ХVI век на него е издигната часовникова кула с височина над 17 метра, все още в много добро състояние. Независимо от значителния си потенциал, Сахат тепе продължава да се свързва с недобре поддържана растителност, еднократни акции за почистване без траен ефект и недобре осветени алеи, осеяни с боклуци.

За сравнение, в Гранада като подстъпи към двореца „Алхамбра“ съществуват няколко различни пешеходни маршрута, някои от които преминават през паркове или съседни квартали с историческо значение. В рамките на ден туристите могат да обиколят множество забележителности, почти без да пресичат автомобилни трасета, а вместо това се наслаждават на реновирани вековни сгради и кокетни площади.

Достъпът до крепостите Алкасаба и Гибралфаро в Малага започва на метри от един от централните площади и приятна разходка води към разцъфнали градини, средновековни укрепления и незабравими гледки към Средиземно море, пристанището и крайбрежните алеи. Преливането между съвременния град и историческата част е плавно, отпадъци по хълмовете не видях и резултатът е хиляди туристи, които всеки ден се запознават с културното наследство на Андалусия.

Сахат тепе може да се превърне в брънка от кипящия живот на Пловдив с няколко стъпки,

като за начало дори не е необходима многомилионна инвестиция. От стотиците служители, работещи в общинската полиция и предприятията „Чистота“, „Градини и паркове“, може да се обособи междуинституционално звено, което да има за задача хълмът да бъде чист, с добре оформени храсти и дървета, без графити по скалите и с постоянна охрана срещу вандалски прояви. Следва поставяне на нови кошчета и пейки с атрактивен дизайн, както и на достатъчно на брой указателни табели, за да се насочва туристическият поток към иначе впечатляващите гледки от високите части. В средносрочен план си струва да се помисли за възстановяване на водните атракции, изграждане на детски площадки и цялостно художествено осветление.

Поглед към бъдещето

В поредица от емблематични научни изследвания и книги датският урбанист Ян Геел насочва към

четири от най-важните характеристики, определящи качеството на градската среда: безопасност, устойчивост, оживеност и стимулиране на здравословни навици.

Поставянето на пешеходците и велосипедистите на преден план са от първостепенно значение, за да се изгради населено място, което да отговаря на тези цели.

Огромният потенциал на Пловдив да се развие като „град за хората“ все още не се осъзнава от местната власт, робуваща на остарели разбирания.

Премахването на подлезите, увеличаването на пешеходните зони и социализацията на Сахат тепе са само три от възможните начини за урбанистична трансформация.

В момента се извършват ремонтни дейности и в други зони с богато културно наследство, като Небет тепе и Източната порта, които също трябва да се включат в туристическите маршрути и постепенно да се припознаят от гражданите за ежедневни разходки.

През последните четири години Здравко Димитров и администрацията му неглижираха пешеходната инфраструктура по недопустим начин, като почти всички инвестиционни разходи на Общината се насочват към ремонти на булеварди на парче. Постигането на привлекателна и зелена визия на центъра на града (и впоследствие на кварталите) би довело до несравнимо повече социално-икономически ползи: увеличаване на туристите, откриване на нови ниши за бизнеса и подобрени възможности за разходка, спорт и прекарване на време на открито за местните жители.

За мен няма съмнение кой е правилният избор в спора между интересите на хората и на автомобилите в контекста на градското планиране. Остава надеждата да сме на едно и също мнение с бъдещите управници на Пловдив, които ще бъдат избрани наесен.

Detecting and stopping recursive loops in AWS Lambda functions

Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/detecting-and-stopping-recursive-loops-in-aws-lambda-functions/

This post is written by Pawan Puthran, Principal Serverless Specialist TAM, Aneel Murari, Senior Serverless Specialist Solution Architect, and Shree Shrikhande, Senior AWS Lambda Product Manager.

AWS Lambda is announcing a recursion control to detect and stop Lambda functions running in a recursive or infinite loop.

At launch, this feature is available for Lambda integrations with Amazon Simple Queue Service (Amazon SQS), Amazon SNS, or when invoking functions directly using the Lambda invoke API. Lambda now detects functions that appear to be running in a recursive loop and drops requests after exceeding 16 invocations.

This can help reduce costs from unexpected Lambda function invocations because of recursion. You receive notifications about this action through the AWS Health Dashboard, email, or by configuring Amazon CloudWatch Alarms.

Overview

You can invoke Lambda functions in multiple ways. AWS services generate events that invoke Lambda functions, and Lambda functions can send messages to other AWS services. In most architectures, the service or resource that invokes a Lambda function should be different from the service or resource that the function outputs to. Because of misconfiguration or coding bugs, a function can send a processed event to the same service or resource that invokes the Lambda function, causing a recursive loop.

Lambda now detects the function running in a recursive loop between supported services, after exceeding 16 invocations. It returns a RecursiveInvocationException to the caller. There is no additional charge for this feature. For asynchronous invokes, Lambda sends the event to a dead-letter queue or on-failure destination, if one is configured.

The following is an example of an order processing system.

Image processing system

Order processing system

  1. A new order information message is sent to the source SQS queue.
  2. Lambda consumes the message from the source queue using an ESM.
  3. The Lambda function processes the message and sends the updated orders message to a destination SQS queue using the SQS SendMessage API.
  4. The source queue has a dead-letter queue(DLQ) configured for handling any failed or unprocessed messages.
  5. Because of a misconfiguration, the Lambda function sends the message to the source SQS queue instead of the destination queue. This causes a recursive loop of Lambda function invocations.

To explore sample code for this example, see the GitHub repo.

In the preceding example, after 16 invocations, Lambda throws a RecursiveInvocationException to the ESM. The ESM stops invoking the Lambda function and, once the maxReceiveCount is exceeded, SQS moves the message to the source queues configured DLQ.

You receive an AWS Health Dashboard notification with steps to troubleshoot the function.

AWS Health Dashboard notification

AWS Health Dashboard notification

You also receive an email notification to the registered email address on the account.

Email notification

Email notification

Lambda emits a RecursiveInvocationsDropped CloudWatch metric, which you can view in the CloudWatch console.

RecursiveInvocationsDropped CloudWatch metric

RecursiveInvocationsDropped CloudWatch metric

How does Lambda detect recursion?

For Lambda to detect recursive loops, your function must use one of the supported AWS SDK versions or higher.

Lambda uses an AWS X-Ray trace header primitive called “Lineage” to track the number of times a function has been invoked with an event. When your function code sends an event using a supported AWS SDK version, Lambda increments the counter in the lineage header. If your function is then invoked with the same triggering event more than 16 times, Lambda stops the next invocation for that event. You do not need to configure active X-Ray tracing for this feature to work.

An example lineage header looks like:

X-Amzn-Trace-Id:Root=1-645f7998-4b1e232810b0bb733dba2eab;Parent=5be88d12eefc1fc0;Sampled=1;Lineage=43e12f0f:5

43e12f0f is the hash of a resource, in this case a Lambda function. 5 is the number of times this function has been invoked with the same event. The logic of hash generation, encoding, and size of the lineage header may change in the future. You should not design any application functionality based on this.

When using an ESM to consume messages from SQS, after the maxReceiveCount value is exceeded, the message is sent to the source queue’s configured DLQ. When Lambda detects a recursive loop and drops subsequent invocations, it returns a RecursiveInvocationException to the ESM. This increments the maxReceiveCount value. When the ESM auto retries to process events, based on the error handling configuration, these retries are not considered recursive invocations.

When using SQS, you can also batch multiple messages into one Lambda event. Where the message batch size is greater than 1, Lambda uses the maximum lineage value within the batch of messages. It drops the entire batch if the value exceeds 16.

Recursion detection in action

You can deploy a sample application example in the GitHub repo to test Lambda recursive loop detection. The application includes a Lambda function that reads from an SQS queue and writes messages back to the same SQS queue.

As prerequisites, you must install:

To deploy the application:

    1. Set your AWS Region:
export REGION=<your AWS region>
    1. Clone the GitHub repository
git clone https://github.com/aws-samples/aws-lambda-recursion-detection-sample.git
cd aws-lambda-recursion-detection-sample
    1. Use AWS SAM to build and deploy the resources to your AWS account. Enter a stack name, such as lambda-recursion, when prompted. Accept the remaining default values.
sam build –-use-container
sam deploy --guided --region $REGION

To test the application:

    1. Save the name of the SQS queue in a local environment variable:
SOURCE_SQS_URL=$(aws cloudformation describe-stacks \ --region $REGION \ --stack-name lambda-recursion \ --query 'Stacks[0].Outputs[?OutputKey==`SourceSQSqueueURL`].OutputValue' --output text)
  1. Publish a message to the source SQS queue:
aws sqs send-message --queue-url $SOURCE_SQS_URL --message-body '{"orderId":"111","productName":"Bolt","orderStatus":"Submitted"}' --region $REGION

This invokes the Lambda function, which writes the message back to the queue.

To verify that Lambda has detected the recursion:

  1. Navigate to the CloudWatch console. Choose All Metrics under Metrics in the left-hand panel and search for RecursiveInvocationsDropped.

    Find RecursiveInvocationsDropped.

    Find RecursiveInvocationsDropped.

  2. Choose Lambda > By Function Name and choose RecursiveInvocationsDropped for the function you created. Under Graphed metrics, change the statistic to sum and Period to 1 minute. You see one record. Refresh if you don’t see the metric after a few seconds.
Metrics sum view

Metrics sum view

Actions to take when Lambda stops a recursive loop

When you receive a notification regarding recursion in your account, the following steps can help address the issue.

  • To stop further invoke attempts while you fix the underlying configuration issue, set the function concurrency to 0. This acts as an off switch for the Lambda function. You can choose the “Throttle” button in the Lambda console or use the PutFunctionConcurrency API to set the function concurrency to 0.
  • You can also disable or delete the event source mapping or trigger for the Lambda function.
  • Check your Lambda function code and configuration for any code defects that create loops. For example, check your environment variables to ensure you are not using the same SQS queue or SNS topic as source and target.
  • If an SQS Queue is the event source for your Lambda function, configure a DLQ on the source queue.
  • If an SNS topic is the event source, configure an On-Failure Destination for the Lambda function.

Disabling recursion detection

You may have valid use-cases where Lambda recursion is intentional as part of your design. In this case, use caution and implement suitable guardrails to prevent unexpected charges to your account. To learn more about best practices for using recursive invocation patterns, see Recursive patterns that cause run-away Lambda functions in the AWS Lambda Operator Guide.

This feature is turned on by default to stop recursive loops. To request turning it off for your account, reach out to AWS Support.

Conclusion

Lambda recursion control for SQS and SNS automatically detects and stops functions running in a recursive or infinite loop. This can be due to misconfiguration or coding errors. Recursion control helps reduce unexpected usage with Lambda and downstream services. The post also explains how Lambda detects and stops recursive loops and notifies you through AWS Health Dashboard to troubleshoot the function.

To learn more about the feature, visit the AWS Lambda Developer Guide.

For more serverless learning resources, visit Serverless Land

AWS Week in Review – AWS Glue Crawlers Now Supports Apache Iceberg, Amazon RDS Updates, and More – July 10, 2023

Post Syndicated from Antje Barth original https://aws.amazon.com/blogs/aws/aws-week-in-review-aws-glue-crawlers-now-supports-apache-iceberg-amazon-rds-updates-and-more-july-10-2023/

The US celebrated Independence Day last week on July 4 with fireworks and barbecues across the country. But fireworks weren’t the only thing that launched last week. Let’s have a look!

Last Week’s Launches
Here are some launches that got my attention:

AWS Glue – AWS Glue Crawlers now supports Apache Iceberg tables. Apache Iceberg is an open-source table format for data stored in data lakes. You can now automatically register Apache Iceberg tables into AWS Glue Data Catalog by running the Glue Crawler. You can then query Glue Catalog Iceberg tables across various analytics engines and apply AWS Lake Formation fine-grained permissions when querying from Amazon Athena. Check out the AWS Glue Crawler documentation to learn more.

Amazon Relational Database Service (Amazon RDS) for PostgreSQL – PostgreSQL 16 Beta 2 is now available in the Amazon RDS Database Preview Environment. The PostgreSQL community released PostgreSQL 16 Beta 2 on June 29, 2023, which enables logical replication from standbys and includes numerous performance improvements. You can deploy PostgreSQL 16 Beta 2 in the preview environment and start evaluating the pre-release of PostgreSQL 16 on Amazon RDS for PostgreSQL.

In addition, Amazon RDS for PostgreSQL Multi-AZ Deployments with two readable standbys now supports logical replication. With logical replication, you can stream data changes from Amazon RDS for PostgreSQL to other databases for use cases such as data consolidation for analytical applications, change data capture (CDC), replicating select tables rather than the entire database, or for replicating data between different major versions of PostgreSQL. Check out the Amazon RDS User Guide for more details.

Amazon CloudWatch – Amazon CloudWatch now supports Service Quotas in cross-account observability. With this, you can track and visualize resource utilization and limits across various AWS services from multiple AWS accounts within a region using a central monitoring account. You no longer have to track the quotas by logging in to individual accounts, instead from a central monitoring account, you can create dashboards and alarms for the AWS service quota usage across all your source accounts from a central monitoring account. Setup CloudWatch cross-account observability to get started.

Amazon SageMaker – You can now associate a SageMaker Model Card with a specific model version in SageMaker Model Registry. This lets you establish a single source of truth for your registered model versions, with comprehensive, centralized, and standardized documentation across all stages of the model’s journey on SageMaker, facilitating discoverability and promoting governance, compliance, and accountability throughout the model lifecycle. Learn more about SageMaker Model Cards in the developer guide.

For a full list of AWS announcements, be sure to keep an eye on the What’s New at AWS page.

Other AWS News
Here are some additional blog posts and news items that you might find interesting:

Building generative AI applications for your startup – In this AWS Startups Blog post, Hrushikesh explains various approaches to build generative AI applications, and reviews their key component. Read the full post for the details.

Components of the generative AI landscape

Components of the generative AI landscape.

How Alexa learned to speak with an Irish accent – If you’re curious how Amazon researchers used voice conversation to generate Irish-accented training data in Alexa’s own voice, check out this Amazon Science Blog post. 

AWS open-source news and updates – My colleague Ricardo writes this weekly open-source newsletter in which he highlights new open-source projects, tools, and demos from the AWS Community.

Upcoming AWS Events
Check your calendars and sign up for these AWS events:

AWS Global Summits – Check your calendars and sign up for the AWS Summit close to where you live or work: Hong Kong (July 20), New York City (July 26), Taiwan (August 2-3), São Paulo (August 3), and Mexico City (August 30).

AWS Community Days – Join a community-led conference run by AWS user group leaders in your region: Malaysia (July 22), Philippines (July 29-30), Colombia (August 12), and West Africa (August 19).

AWS re:Invent 2023AWS re:Invent (November 27 – December 1) – Join us to hear the latest from AWS, learn from experts, and connect with the global cloud community. Registration is now open.

You can browse all upcoming in-person and virtual events.

That’s all for this week. Check back next Monday for another Week in Review!

— Antje

This post is part of our Week in Review series. Check back each week for a quick roundup of interesting news and announcements from AWS!

Three New AMD EPYC Genoa-X SKUs with up to 48MB L3 cache per Core or 1.1GB Total

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/three-new-amd-epyc-genoa-x-skus-with-up-to-48mb-l3-cache-per-core-or-1-1gb-total/

The AMD EPYC Genoa-X has three SKUs ranging from a massive 96 core, 1.1GB L3 cache part to a crazy 16-core 48MB L3 cache per core CPU

The post Three New AMD EPYC Genoa-X SKUs with up to 48MB L3 cache per Core or 1.1GB Total appeared first on ServeTheHome.

Designing a hybrid AI/ML data access strategy with Amazon SageMaker

Post Syndicated from Franklin Aguinaldo original https://aws.amazon.com/blogs/architecture/designing-a-hybrid-ai-ml-data-access-strategy-with-amazon-sagemaker/

Over time, many enterprises have built an on-premises cluster of servers, accumulating data, and then procuring more servers and storage. They often begin their ML journey by experimenting locally on their laptops. Investment in artificial intelligence (AI) is at a different stage in every business organization. Some remain completely on-premises, others are hybrid (both on-premises and cloud), and the remaining have moved completely into the cloud for their AI and machine learning (ML) workloads.

These enterprises are also researching or have started using the cloud to augment their on-premises systems for several reasons. As technology improves, both the size and quantity of data increases over time. The amount of data captured and the number of datapoints continues to expand, which presents a challenge to manage on-premises. Many enterprises are distributed, with offices in different geographic regions, continents, and time zones. While it is possible to increase the on-premises footprint and network pipes, there are still hidden costs to consider for maintenance and upkeep. These organizations are looking to the cloud to shift some of that effort and enable them to burst and use the rich AI and ML features on the cloud.

Defining a hybrid data access strategy

Moving ML workloads into the cloud calls for a robust hybrid data strategy describing how and when you will connect your on-premises data stores to the cloud. For most, it makes sense to make the cloud the source of truth, while still permitting your teams to use and curate datasets on-premises. Defining the cloud as source of truth for your datasets means the primary copy will be in the cloud and any dataset generated will be stored in the same location in the cloud. This ensures that requests for data is served from the primary copy and any derived copies.

A hybrid data access strategy should address the following:

Understand your current and future storage footprint for ML on-premises. Create a map of your ML workloads, along with performance and access requirements for testing and training.
Define connectivity across on-premises locations and the cloud. This includes east-west and north-south traffic to support interconnectivity between sites, required bandwidth, and throughput for the data movement workload requirements.
Define your single source of truth (SSOT)[1] and where the ML datasets will primarily live. Consider how dated, new, hot, and cold data will be stored.
Define your storage performance requirements, mapping them to the appropriate cloud storage services. This will give you the ability to take advantage of cloud-native ML with Amazon SageMaker.

Hybrid data access strategy architecture

To help address these challenges, we worked on outlining an end-to-end system architecture in Figure 1 that defines: 1) connectivity between on-premises data centers and AWS Regions; 2) mappings for on-premises data to the cloud; and 3) Aligning Amazon SageMaker to appropriate storage, based on ML requirements.

AI/ML hybrid data access strategy reference architecture

Figure 1. AI/ML hybrid data access strategy reference architecture

Let’s explore this architecture step by step.

  1. On-premises connectivity to the AWS Cloud runs through AWS Direct Connect for high transfer speeds.
  2. AWS DataSync is used for migrating large datasets into Amazon Simple Storage Service (Amazon S3). AWS DataSync agent is installed on-premises.
  3. On-premises network file system (NFS) or server message block (SMB) data is bridged to the cloud through Amazon S3 File Gateway, using either a virtual machine (VM) or hardware appliance.
  4. AWS Storage Gateway uploads data into Amazon S3 and caches it on-premises.
  5. Amazon S3 is the source of truth for ML assets stored on the cloud.
  6. Download S3 data for experimentation to Amazon SageMaker Studio.
  7. Amazon SageMaker notebooks instances can access data through S3, Amazon FSx for Lustre, and Amazon Elastic File System. Use Amazon File Cache for high-speed caching for access to on-premises data, and Amazon FSx for NetApp ONTAP for cloud bursting.
  8. SageMaker training jobs can use data in Amazon S3, EFS, and FSx for Lustre. S3 data is accessed via File, Fast File, or Pipe mode, and pre-loaded or lazy-loaded when using FSx for Lustre as training job input. Any existing data on EFS can also be made available to training jobs as well.
  9. Leverage Amazon S3 Glacier for archiving data and reducing storage costs.

ML workloads using Amazon SageMaker

Let’s go deeper into how SageMaker can help you with your ML workloads.

To start mapping ML workloads to the cloud, consider which AWS storage services work with Amazon SageMaker. Amazon S3 typically serves as the central storage location for both structured and unstructured data that is used for ML. This includes raw data coming from upstream applications, and also curated datasets that are organized and stored as part of a Feature Store.

In the initial phases of development, a SageMaker Studio user will leverage S3 APIs to download data from S3 to their private home directory. This home directory is backed by a SageMaker-managed EFS file system. Studio users then point their notebook code (also stored in the home directory) to the local dataset and begin their development tasks.

To scale up and automate model training, SageMaker users can launch training jobs that run outside of the SageMaker Studio notebook environment. There are several options for making data available to a SageMaker training job.

  1. Amazon S3. Users can specify the S3 location of the training dataset. When using S3 as a data source, there are three input modes to choose from:
    • File mode. This is the default input mode, where SageMaker copies the data from S3 to the training instance storage. This storage is either a SageMaker-provisioned Amazon Elastic Block Store (Amazon EBS) volume or an NVMe SSD that is included with specific instance types. Training only starts after the dataset has been downloaded to the storage, and there must be enough storage space to fit the entire dataset.
    • Fast file mode. Fast file mode exposes S3 objects as a POSIX file system on the training instance. Dataset files are streamed from S3 on demand, as the training script reads them. This means that training can start sooner and require less disk space. Fast file mode also does not require changes to the training code.
    • Pipe mode. Pipe input also streams data in S3 as the training script reads it, but requires code changes. Pipe input mode is largely replaced by the newer and easier-to-use Fast File mode.
  2. FSx for Lustre. Users can specify a FSx for Lustre file system, which SageMaker will mount to the training instance and run the training code. When the FSx for Lustre file system is linked to a S3 bucket, the data can be lazily loaded from S3 during the first training job. Subsequent training jobs on the same dataset can then access it with low latency. Users can also choose to pre-load the file system with S3 data using hsm_restore commands.
  3. Amazon EFS. Users can specify an EFS file system that already contains their training data. SageMaker will mount the file system on the training instance and run the training code.
    Find out how to Choose the best data source for your SageMaker training job.

Conclusion

With this reference architecture, you can develop and deliver ML workloads that run either on-premises or in the cloud. Your enterprise can continue using its on-premises storage and compute for particular ML workloads, while also taking advantage of the cloud, using Amazon SageMaker. The scale available on the cloud allows your enterprise to conduct experiments without worrying about capacity. Start defining your hybrid data strategy on AWS today!

Additional resources:

[1] The practice of aggregating data from many sources to a single source or location.

[$] The rest of the 6.5 merge window

Post Syndicated from original https://lwn.net/Articles/937006/

Linus Torvalds released
6.5-rc1
and closed the merge window for this development cycle on
July 9. By that point, 11,730 non-merge changesets had been pulled
into the mainline for 6.5; over 7,700 of those were pulled after
the first-half merge-window summary was
written. The second half of the merge window saw a lot of code coming into
the mainline and a long list of significant changes.

Security updates for Monday

Post Syndicated from original https://lwn.net/Articles/937803/

Security updates have been issued by Debian (firefox-esr, fusiondirectory, ocsinventory-server, php-cas, and thunderbird), Fedora (dav1d, perl-CPAN, and yt-dlp), Red Hat (python39:3.9 and python39-devel:3.9), Slackware (mozilla), SUSE (prometheus-ha_cluster_exporter and prometheus-sap_host_exporter), and Ubuntu (ghostscript, linux-azure, linux-intel-iotg, linux-intel-iotg-5.15, and ruby-doorkeeper).

Apply for a free UK teacher’s place at the WiPSCE conference

Post Syndicated from Bonnie Sheppard original https://www.raspberrypi.org/blog/free-uk-teacher-places-wipsce-conference-2023/

From 27 to 29 September 2023, we and the University of Cambridge are hosting the WiPSCE International Workshop on Primary and Secondary Computing Education Research for educators and researchers. This year, this annual conference will take place at Robinson College in Cambridge. We’re inviting all UK-based teachers of computing subjects to apply for one of five ‘all expenses paid’ places at this well-regarded annual event.

Educators and researchers mingle at a conference.

You could attend WiPSCE with all expenses paid

WiPSCE is where teachers and researchers discuss research that’s relevant to teaching and learning in primary and secondary computing education, to teacher training, and to related topics. You can find more information about the conference, including the preliminary programme, at wipsce.org. 

As a teacher at the conference, you will:

  • Engage with high-quality international research in the field where you teach
  • Learn ways to use that research to develop your own classroom practice
  • Find out how to become an advocate in your professional community for research-informed approaches to the teaching of computing.

We are delighted that, thanks to generous funding from a funder, we can offer five free places to UK computing teachers, covering:

  • The registration fee
  • Two nights’ accommodation at Robinson College
  • Up to £500 supply costs paid to your school to cover your teaching
  • Up to £100 travel costs

The application deadline is Wednesday 19 July.

The application details

To be eligible to apply:

  1. You need to be a currently practising, UK-based teacher of Computing (England), Computing Science (Scotland), ICT or Digital Technologies (N. Ireland), or Computer Science (Wales)
  2. Your headteacher needs to be able to provide written confirmation that they are happy for you to attend WiPSCE
  3. You need to be available to attend the whole conference from Wednesday lunchtime to Friday afternoon
  4. You need to be willing to share what you learn from the conference with your colleagues at school and with your broader teaching community, including through writing an article about your experience and its relevance to your teaching for this blog or Hello World magazine

The application form will ask your for:

  • Your name and contact details
  • Demographic and school information
  • Your teaching experience
  • A statement of up to 500 words on why you’re applying and how you think your teaching practice, your school and your colleagues will benefit from your attendance at WiPSCE (500 words is the maximum, feel free to be concise)

After the 19 July deadline, we’re aiming to inform you of the outcome of your application on Friday 21 July. 

Your application will be reviewed by the 2023 WiPSCE Chairs:

Sue and Mareen will:

  • Use the information you share in your form, particularly in your statement
  • Select applicants from a mix of primary and secondary schools, with a mix of years of computing teaching experience, and from a mix of geographic areas

Join us in strengthening research-informed computing classroom practice

We’d be delighted to receive your application. Being able to facilitate teachers’ attendance at the conference is very much aligned with our approach to research. Both at the Foundation and the Raspberry Pi Computing Education Research Centre, we’re committed to conducting research that’s directly relevant to schools and teachers, and to working in close collaboration with teachers.

We hope you are interested in attending WiPSCE and becoming an advocate for research-informed computing education practice. If your application is unsuccessful, we hope you consider coming along anyway. We’re looking forward to meeting you there. In the meantime, you can keep up with WiPSCE news on Twitter.

The post Apply for a free UK teacher’s place at the WiPSCE conference appeared first on Raspberry Pi Foundation.

How Cloudflare Images addressed the aCropalypse vulnerability

Post Syndicated from Nicholas Skehin original http://blog.cloudflare.com/how-cloudflare-images-addressed-the-acropalypse-vulnerability/

How Cloudflare Images addressed the aCropalypse vulnerability

How Cloudflare Images addressed the aCropalypse vulnerability

Acropalypse (CVE-2023-21036) is a vulnerability caused by image editing tools failing to truncate images when editing has made them smaller, most often seen when images are cropped. This leaves remnants of the cropped contents written in the file after the image has finished. The remnants (written in a ‘trailer’ after the end-of-image marker) are ignored by most software when reading the image, but can be used to partially reconstruct the original image by an attacker.

The general class of vulnerability can, in theory, affect any image format if it ignores data written after the end of the image. In this case the applications affected were the ‘Markup’ screenshot editor that shipped with Google Pixel phones from the Pixel 3 (saving its images in the PNG format) and the Windows Snipping tool (with both PNG and JPEG formats).

Our customers deliver their images using Cloudflare Images products and may have images that are affected. We would like to ensure their images are protected from this vulnerability if they have been edited using a vulnerable editor.

As a concrete example, imagine a Cloudflare customer running a social network, delivering images using Cloudflare Images. A user of the social network might take a screenshot of an invoice containing their address after ordering a product, crop their address out and share the cropped image on the social network. If the image was cropped using an editor affected by aCropalypse an attacker would be able to recover their address, violating their expectation of privacy.

How Cloudflare Images products works

Cloudflare Images and Image Resizing use a proxy as the upstream for requests. This proxy fetches the original image (from either Cloudflare Images storage or the customer’s upstream), applies any transformations (from the variant definition for Cloudflare Images, or from the URL/worker parameters for Image Resizing) and then responds with the transformed image.

This naturally provides protection against aCropalypse for our customers: the proxy will ignore any trailing data in the input, so it won’t be present in the re-encoded image.

However, for certain requests, the proxy might respond with the original. This occurs when two conditions hold: the original can satisfy the request and the re-encoded image has a larger file size. The original satisfies the request if we can guarantee that if the requested format is supported the original format will be supported, it has the same dimensions, it doesn’t have any metadata that needs stripping and it doesn’t have any other transformations such as sharpening or overlays.

Even if the original can satisfy the request, it is fairly unlikely the original will be smaller for images affected by aCropalypse as the leaked information in the trailer will increase the file size. So Cloudflare Images and Image Resizing should provide protection against aCropalypse without adding any additional mitigations.

That being said, we couldn’t guarantee that images affected by aCropalypse would always be re-encoded. We wanted to be able to offer this guarantee for customers of Cloudflare Images and Image Resizing.

How we addressed the issue for JPEG and PNG file format

To ensure that no images with a trailer will ever be passed through, we can add another requirement to reply with the original image — if the original image is a PNG or a JPEG (so might have been affected by aCropalypse), it must not have a trailer. Then we just need to be able to detect trailers for both formats.

As a first idea we might consider simply checking that the image ends with the correct end-of-image marker, which for JPEG is the byte sequence [0xFF 0xD9] and for PNG is the byte sequence [0x00 0x00 0x00 0x00 0x49 0x45 0x4E 0x44 0xAE 0x42 0x60 0x82]. But this won’t work for images affected by aCropalypse: because the original image was a valid image, the trailer that results from overwriting the start of the file will be the end of a valid image. We also can’t check whether there is more than one end-of-image marker in the file; both formats have chunks of variable-length bytestrings in which the end-of-image marker could appear. We need to do it properly by parsing the image’s structure and checking there is no data after its end.

For JPEGs, we use a Rust wrapper of the library libjpeg-turbo for decoding. Libjpeg-turbo allows fine control of resource usage; for example it allows decompressing and re-compressing a JPEG file a scanline at a time. This flexibility allows us to easily detect trailers using the library’s API: we just have to check that once we have consumed the end-of-image marker all of the input has been consumed. In our proxy we use an in-memory buffer as input, so we can check that there are no bytes left in the buffer:

pub fn consume_eoi_marker(&mut self) -> bool {
    // Try to consume the EOI marker of the image
    unsafe {
        (ffi::jpeg_input_complete(&self.dec.cinfo) == 1) || {
            ffi::jpeg_consume_input(&mut self.dec.cinfo);
            ffi::jpeg_input_complete(&self.dec.cinfo) == 1
        }
    }
}

pub fn has_trailer(&mut self) -> io::Result<bool> {
    if self.consume_eoi_marker() {
        let src = unsafe {
            NonNull::new(self.dec.cinfo.src)
                .ok_or_else(|| {
                    io::Error::new(
                        io::ErrorKind::Other,
                        "source manager not set".to_string()
                    )
                })?
                .as_ref()
        };

        // We have a trailer if we have any bytes left over in the buffer
        Ok(src.bytes_in_buffer != 0)
    } else {
        // We didn't consume the EOI - we can't say if there is a trailer
        Err(io::Error::new(
            io::ErrorKind::Other,
            "EOI not reached".to_string(),
        ))
    }
}

For PNGs, we use the lodepng library. This has a much simpler API surface that decodes an image in one shot when you call lodepng_decode. This doesn’t tell us how many bytes were read or provide an interface to detect if we have a trailer.

Luckily the PNG format has a very consistent and simple internal structure:

  • First the PNG prelude, the byte sequence [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a]
  • Then a series of chunks, which each consist of
  1. 4 bytes length as a big-endian integer N
  2. 4 bytes chunk type
  3. N bytes of data (whose meaning depends on the chunk type)
  4. 4 bytes of checksum — CRC-32 of the type and data

The file is terminated by a chunk of type IEND with no data.

As the format is so regular, it’s easy to write a separate parser that just reads the prelude, loops through the chunks until we see IEND, and then checks if we have any bytes left. We can perform this check after decoding the image with lodepng, as this allows us to skip validating the checksums as lodepng has already checked them for us:

const PNG_PRELUDE: &[u8] = &[0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a];

enum ChunkStatus {
    SeenEnd { has_trailer: bool },
    MoreChunks,
}

fn consume_chunks_until_iend(buf: &[u8]) -> Result<(ChunkStatus, &[u8]), &'static str> {
    let (length_bytes, buf) = consume(buf, 4)?;
    let (chunk_type, buf) = consume(buf, 4)?;

    // Infallible: We've definitely consumed 4 bytes
    let length = u32::from_be_bytes(length_bytes.try_into().unwrap());

    let (_data, buf) = consume(buf, length as usize)?;

    let (_checksum, buf) = consume(buf, 4)?;

    if chunk_type == b"IEND" && buf.is_empty() {
        Ok((ChunkStatus::SeenEnd { has_trailer: false }, buf))
    } else if chunk_type == b"IEND" && !buf.is_empty() {
        Ok((ChunkStatus::SeenEnd { has_trailer: true }, buf))
    } else {
        Ok((ChunkStatus::MoreChunks, buf))
    }
}

pub(crate) fn has_trailer(png_data: &[u8]) -> Result<bool, &'static str> {
    let (magic, mut buf) = consume(png_data, PNG_PRELUDE.len())?;

    if magic != PNG_PRELUDE {
        return Err("expected prelude");
    }

    loop {
        let (status, tmp_buf) = consume_chunks_until_iend(buf)?;
        buf = tmp_buf;
        if let ChunkStatus::SeenEnd { has_trailer } = status {
            return Ok(has_trailer)
        }
    }
}

Conclusion

Customers using Cloudflare Images or Image Resizing products are protected against the aCropalypse vulnerability. The Images team addressed the vulnerability in a way that didn’t require any changes to the original images or cause any increased latency or regressions for customers.

Wisconsin Governor Hacks the Veto Process

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/07/wisconsin-governor-hacks-the-veto-process.html

In my latest book, A Hacker’s Mind, I wrote about hacks as loophole exploiting. This is a great example: The Wisconsin governor used his line-item veto powers—supposedly unique in their specificity—to change a one-year funding increase into a 400-year funding increase.

He took this wording:

Section 402. 121.905 (3) (c) 9. of the statues is created to read: 121.903 (3) (c) 9. For the limit for the 2023-24 school year and the 2024-25 school year, add $325 to the result under par. (b).

And he deleted these words, numbers, and punctuation marks:

Section 402. 121.905 (3) (c) 9. of the statues is created to read: 121.903 (3) (c) 9. For the limit for the 2023-24 school year and the 2024–25 school year, add $325 to the result under par. (b).

Seems to be legal:

Rick Champagne, director and general counsel of the nonpartisan Legislative Reference Bureau, said Evers’ 400-year veto is lawful in terms of its form because the governor vetoed words and digits.

“Both are allowable under the constitution and court decisions on partial veto. The hyphen seems to be new, but the courts have allowed partial veto of punctuation,” Champagne said.

Definitely a hack. This is not what anyone thinks about when they imagine using a line-item veto.

And it’s not the first time. I don’t know the details, but this was certainly the same sort of character-by-character editing:

Mr Evers’ Republican predecessor once deploying it to extend a state programme’s deadline by one thousand years.

A couple of other things:

One, this isn’t really a 400-year change. Yes, that’s what the law says. But it can be repealed. And who knows that a dollar will be worth—or if they will even be used—that many decades from now.

And two, from now all Wisconsin lawmakers will have to be on the alert for this sort of thing. All contentious bills will be examined for the possibility of this sort of delete-only rewriting. This sentence could have been reworded, for example:

For the 2023-2025 school years, add $325 to the result under par. (b).

The problem is, of course, that legalese developed over the centuries to be extra wordy in order to limit disputes. If lawmakers need to state things in the minimal viable language, that will increase court battles later. And that’s not even enough. Bills can be thousands of words long. If any arbitrary characters can be glued together by deleting enough other characters, bills can say anything the governor wants.

The real solution is to return the line-item veto to what we all think it is: the ability to remove individual whole provisions from a law before signing it.

Running GitHub Actions in a private Subnet with AWS CodeBuild

Post Syndicated from original https://aws.amazon.com/blogs/devops/running-github-actions-in-a-private-subnet-with-aws-codebuild/

Last week the Developer Tools team announced that AWS CodeBuild now supports GitHub Actions. AWS CodeBuild is a fully managed continuous integration service that allows you to build and test code. CodeBuild builds are defined as a collection of build commands and related settings, in YAML format, called a BuildSpec. You can now define GitHub Actions steps directly in the BuildSpec and run them alongside CodeBuild commands. In this post, I will use the Liquibase GitHub Action to deploy changes to an Amazon Aurora database in a private subnet.

Background

The GitHub Marketplace includes a large catalog of actions developed by third-parties and the open-source community. At the time of writing, there are nearly 20,000 actions available in the marketplace. Using an action from the marketplace can save you time and effort that would be spent scripting the installation and configuration of various tools required in the build process.

While I love GitHub actions, I often what to run my build in AWS. For example, I might want to access a resource in a private VPC or simply reduce the latency between the build service and my resources. I could accomplish this by hosting a GitHub Action Runner on Amazon Elastic Compute Cloud (Amazon EC2). However, hosting a GitHub Action runner requires additional effort to configure and maintain the environment that hosts the runner.

AWS CodeBuild is a fully managed continuous integration service. CodeBuild does not require ongoing maintenance and it can access resources in a private subnet. You can now use GitHub Actions in AWS CodeBuild. This feature provides the simplified configuration and management of CodeBuild with the rich marketplace of GitHub Actions. In the following section, I will explain how to configure CodeBuild to run a GitHub Action.

Walkthrough

In this walkthrough, I will configure AWS CodeBuild to use the Liquibase GitHub Action to deploy changelogs to a PostgreSQL database hosted on Amazon Aurora in a private subnet. As shown in the following image, AWS CodeBuild will be configured to run in a private subnet along with my Aurora instance. First, CodeBuild will download the GitHub action using a NAT Gateway to access the internet. Second, CodeBuild will apply the changelog to the Aurora instance in the private subnet.

Architecture diagram showing CodeBuild and Aurora in a private subnet with internet access provided by a NAT gateway

I already have a GitHub repository with the Liquibase configuration properties and changelogs shown in the following image. Liquibase configuration is not the focus of this blog post, but you can read more in Getting Started with Liquibase. My source also includes the buildspec.yaml file which I will explain later in this post.

GitHub repository with Liquibase change set

To create my build project, I open CodeBuild in the AWS Console and select Create build project. Then I provide a name and optional description for the build. My project is named liquibase-blog-post.

If you are note already connected to GitHub, you can connect using a personal access token as shown in the following image.

GitHub configuration in CodeBuild showing the GitHub personal access token

Once I have successfully connected to GitHub, I can paste the URL to my repository as shown in the following image.

CodeBuild configuration showing the GitHub repository URL

I configure my build environment to use the standard build environment on Amazon Linux 2. GitHub actions are built using either JavaScript or a Docker container. If the action uses a Docker container, you must enable the Privileged flag. The Liquibase image is using a Docker container, therefore, I check the box to enabled privileged mode.

Environment configuration showing the standard image on Linux and the privileged flag enabled.

For the VPC configuration, I select the VPC and private subnet where my Aurora instance is hosted and then click Validate VPC Settings to ensure my configuration is correct.

VPC configuration with private subnet selected

My Buildspec file is included I the source. Therefore, I select Use a buildspec file and enter the path to the buildspec file in the repository.

Buildspec configuration with Use a build spec file selected

My buildspec.yaml file includes the following content. Notice that the pre_build phase incudes a series of commands. Commands have always been supported in CodeBuild and include a series of command line commands to run. In this case, I am simply logging a few environment variables for later debugging.

version: 0.2
phases:
  pre_build:
    commands:
      - echo $AWS_DEFAULT_REGION
      - echo $URL
  build: 
    steps:
      - uses: liquibase-github-actions/[email protected]
        with:
          changelogFile: changelog-root.xml
          url: ${{ env.URL }}
          username: postgres
          password: ${{ $env.PASSWORD }}
          headless: true

Also notice that the build phase incudes a series of steps. Steps are new, and are used to run GitHub Actions. Each build phase supports either a list of commands, or a list of steps, but not both. In this example, I am specifying the Liquibase Update Action (liquibase-github-actions/update) with a few configuration parameters. You can see a full list of parameters in the Liquibase Update Action repository on GitHub.

I want to call you attention to the environment variables used in my buildspec.yml. Note that I pass the URL and PASSWORD for my database as environment variables. This allows me easily change these values from one environment to another. I have configured these environment variables in the CodeBuild project definition as shown in the following image. The URL is configured as Plaintext and the PASSWORD is configured as Secrets Manager. Running the GitHub Action in CodeBuild has the added advantage that I easily access secrets stored in AWS Secrets Manager and configuration data stored in AWS Systems Manager Parameter Store.

Environment Variables used to configure the URL and PASSWORD.

It is also important to note that the syntax use to access environment variables in the buildspec.yaml is different when using a GitHub Action. GitHub Actions access environment variables using the environment context. Therefore, in the pre_build phase, I am using CodeBuild syntax, in the format $NAME. However, the in the build phase, I am using GitHub syntax, in the format ${{ env:NAME}}.

With the configuration complete, I select Create build project and then manually start a build to test the configuration. In the following example you can see the logs from the Liquibase update. Notice that two changesets have been successfully applied to the database.


####################################################
##   _     _             _ _                      ##
##  | |   (_)           (_) |                     ##
##  | |    _  __ _ _   _ _| |__   __ _ ___  ___   ##
##  | |   | |/ _` | | | | | '_ \ / _` / __|/ _ \  ##
##  | |___| | (_| | |_| | | |_) | (_| \__ \  __/  ##
##  \_____/_|\__, |\__,_|_|_.__/ \__,_|___/\___|  ##
##              | |                               ##
##              |_|                               ##
##                                                ##
##  Get documentation at docs.liquibase.com       ##
##  Get certified courses at learn.liquibase.com  ##
##  Free schema change activity reports at        ##
##      https://hub.liquibase.com                 ##
##                                                ##
####################################################
Starting Liquibase at 18:33:23 (version 4.21.1 #9070)
Liquibase Version: 4.21.1
Liquibase Open Source 4.21.1 by Liquibase
Running Changeset: changelogs/changelog-1.0.0.xml::1::BobR
Running Changeset: changelogs/changelog-1.0.1.xml::2::BobR
  
UPDATE SUMMARY
Run: 2
Previously run: 0
Filtered out: 0
-------------------------------
Total change sets: 2
  
Liquibase: Update has been successful.
Liquibase command 'update' was executed successfully.
  
Phase complete: BUILD State: SUCCEEDED
Phase context status code: Message:
Entering phase POST_BUILD

If I connect to the Aurora database and describe the tables you can see that Liquibase has created the actor table (as defined in the Liquibase Quick Start) along with the Liquibase audit tables databasechangelog and databasechangeloglock. Everything is working just as I expected, and I did not have to install and configure Liquibase!


mydatabase=> \dt
List of relations
Schema  |         Name          | Type  |  Owner
--------+-----------------------+-------+----------
public  | actor                 | table | postgres
public  | databasechangelog     | table | postgres
public  | databasechangeloglock | table | postgres
(3 rows)

In this example, I showed you how to update an Aurora database in a private subnet using a the Liquibase GitHub Action running in CodeBuild. GitHub Actions provide a rich catalog of preconfigured actions simplifying the configuration. CodeBuild provides a managed service that simplifies the configuration and maintenance of my build environment. Used together I can get the best features of both CodeBuild and GitHub Actions.

Cleanup

In this walkthrough I showed you how to create a CodeBuild project. If you no longer need the project, you can simply delete it in the console. If you created other resources, for example an Aurora database, that were not explained in this post, you should delete those as well.

Conclusion

The GitHub Marketplace includes a catalog of nearly 20,000 actions developed by third-parties and the open-source community. AWS CodeBuild is a fully managed continuous integration service that integrates tightly with other AWS services. In this post I used the GitHub Action for Liquibase to deploy an update to a database in a private subnet. I am excited to see what you will do with support for GitHub Actions in CodeBuild. You can read more about this exciting new feature in GitHub Action runner in AWS CodeBuild.

Automated Code Review on Pull Requests using AWS CodeCommit and AWS CodeBuild

Post Syndicated from Verinder Singh original https://aws.amazon.com/blogs/devops/automated-code-review-on-pull-requests-using-aws-codecommit-and-aws-codebuild/

Pull Requests play a critical part in the software development process. They ensure that a developer’s proposed code changes are reviewed by relevant parties before code is merged into the main codebase. This is a standard procedure that is followed across the globe in different organisations today. However, pull requests often require code reviewers to read through a great deal of code and manually check it against quality and security standards. These manual reviews can lead to problematic code being merged into the main codebase if the reviewer overlooks any problems.

To help solve this problem, we recommend using Amazon CodeGuru Reviewer to assist in the review process. CodeGuru Reviewer identifies critical defects and deviation from best practices in your code. It provides recommendations to remediate its findings as comments in your pull requests, helping reviewers miss fewer problems that may have otherwise made into production. You can easily integrate your repositories in AWS CodeCommit with Amazon CodeGuru Reviewer following these steps.

The purpose of this post isn’t, however, to show you CodeGuru Reviewer. Instead, our aim is to help you achieve automated code reviews with your pull requests if you already have a code scanning tool and need to continue using it. In this post, we will show you step-by-step how to add automation to the pull request review process using your code scanning tool with AWS CodeCommit (as source code repository) and AWS CodeBuild (to automatically review code using your code reviewer). After following this guide, you should be able to give developers automatic feedback on their code changes and augment manual code reviews so fewer problems make it into your main codebase.

Solution Overview

The solution comprises of the following components:

  1. AWS CodeCommit: AWS service to host private Git repositories.
  2. Amazon EventBridge: AWS service to receive pullRequestCreated and pullRequestSourceBranchUpdated events and trigger Amazon EventBridge rule.
  3. AWS CodeBuild: AWS service to perform code review and send the result to AWS CodeCommit repository as pull request comment.

The following diagram illustrates the architecture:

Figure 1: This architecture diagram illustrates the workflow where developer raises a Pull Request and receives automated feedback on the code changes using AWS CodeCommit, AWS CodeBuild and Amazon EventBridge rule

Figure 1. Architecture Diagram of the proposed solution in the blog

  1. Developer raises a pull request against the main branch of the source code repository in AWS CodeCommit.
  2. The pullRequestCreated event is received by the default event bus.
  3. The default event bus triggers the Amazon EventBridge rule which is configured to be triggered on pullRequestCreated and pullRequestSourceBranchUpdated events.
  4. The EventBridge rule triggers AWS CodeBuild project.
  5. The AWS CodeBuild project runs the code quality check using customer’s choice of tool and sends the results back to the pull request as comments. Based on the result, the AWS CodeBuild project approves or rejects the pull request automatically.

Walkthrough

The following steps provide a high-level overview of the walkthrough:

  1. Create a source code repository in AWS CodeCommit.
  2. Create and associate an approval rule template.
  3. Create AWS CodeBuild project to run the code quality check and post the result as pull request comment.
  4. Create an Amazon EventBridge rule that reacts to AWS CodeCommit pullRequestCreated and pullRequestSourceBranchUpdated events for the repository created in step 1 and set its target to AWS CodeBuild project created in step 3.
  5. Create a feature branch, add a new file and raise a pull request.
  6. Verify the pull request with the code review feedback in comment section.

1. Create a source code repository in AWS CodeCommit

Create an empty test repository in AWS CodeCommit by following these steps. Once the repository is created you can add files to your repository following these steps. If you create or upload the first file for your repository in the console, a branch is created for you named main. This branch is the default branch for your repository. If you are using a Git client instead, consider configuring your Git client to use main as the name for the initial branch. This blog post assumes the default branch is named as main.

2. Create and associate an approval rule template

Create an AWS CodeCommit approval rule template and associate it with the code repository created in step 1 following these steps.

3. Create AWS CodeBuild project to run the code quality check and post the result as pull request comment

This blog post is based on the assumption that the source code repository has JavaScript code in it, so it uses jshint as a code analysis tool to review the code quality of those files. However, users can choose a different tool as per their use case and choice of programming language.

Create an AWS CodeBuild project from AWS Management Console following these steps and using below configuration:

  • Source: Choose the AWS CodeCommit repository created in step 1 as the source provider.
  • Environment: Select the latest version of AWS managed image with operating system of your choice. Choose New service role option to create the service IAM role with default permissions.
  • Buildspec: Use below build specification. Replace <NODEJS_VERSION> with the latest supported nodejs runtime version for the image selected in previous step. Replace <REPOSITORY_NAME> with the repository name created in step 1. The below spec installs the jshint package, creates a jshint config file with a few sample rules, runs it against the source code in the pull request commit, posts the result as comment to the pull request page and based on the results, approves or rejects the pull request automatically.
version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: <NODEJS_VERSION>
    commands:
      - npm install jshint --global
  build:
    commands:
      - echo \{\"esversion\":6,\"eqeqeq\":true,\"quotmark\":\"single\"\} > .jshintrc
      - CODE_QUALITY_RESULT="$(echo \`\`\`) $(jshint .)"; EXITCODE=$?
      - aws codecommit post-comment-for-pull-request --pull-request-id $PULL_REQUEST_ID --repository-name <REPOSITORY_NAME> --content "$CODE_QUALITY_RESULT" --before-commit-id $DESTINATION_COMMIT_ID --after-commit-id $SOURCE_COMMIT_ID --region $AWS_REGION	
      - |
        if [ $EXITCODE -ne 0 ]
        then
          PR_STATUS='REVOKE'
        else
          PR_STATUS='APPROVE'
        fi
      - REVISION_ID=$(aws codecommit get-pull-request --pull-request-id $PULL_REQUEST_ID | jq -r '.pullRequest.revisionId')
      - aws codecommit update-pull-request-approval-state --pull-request-id $PULL_REQUEST_ID --revision-id $REVISION_ID --approval-state $PR_STATUS --region $AWS_REGION

Once the AWS CodeBuild project has been created successfully, modify its IAM service role by following the below steps:

  • Choose the CodeBuild project’s Build details tab.
  • Choose the Service role link under the Environment section which should navigate you to the CodeBuild’s IAM service role in IAM console.
  • Expand the default customer managed policy and choose Edit.
  • Add the following actions to the existing codecommit actions:
"codecommit:CreatePullRequestApprovalRule",
"codecommit:GetPullRequest",
"codecommit:PostCommentForPullRequest",
"codecommit:UpdatePullRequestApprovalState"

  • Choose Next.
  • On the Review screen, choose Save changes.

4. Create an Amazon EventBridge rule that reacts to AWS CodeCommit pullRequestCreated and pullRequestSourceBranchUpdated events for the repository created in step 1 and set its target to AWS CodeBuild project created in step 3

Follow these steps to create an Amazon EventBridge rule that gets triggered whenever a pull request is created or updated using the following event pattern. Replace the <REGION>, <ACCOUNT_ID> and <REPOSITORY_NAME> placeholders with the actual values. Select target of the event rule as AWS CodeBuild project created in step 3.

Event Pattern

{
    "detail-type": ["CodeCommit Pull Request State Change"],
    "resources": ["arn:aws:codecommit:<REGION>:<ACCOUNT_ID>:<REPOSITORY_NAME>"],
    "source": ["aws.codecommit"],
    "detail": {
      "isMerged": ["False"],
      "pullRequestStatus": ["Open"],
      "repositoryNames": ["<REPOSITORY_NAME>"],
      "destinationReference": ["refs/heads/main"],
      "event": ["pullRequestCreated", "pullRequestSourceBranchUpdated"]
    },
    "account": ["<ACCOUNT_ID>"]
  }

Follow these steps to configure the target input using the below input path and input template.

Input transformer – Input path

{
    "detail-destinationCommit": "$.detail.destinationCommit",
    "detail-pullRequestId": "$.detail.pullRequestId",
    "detail-sourceCommit": "$.detail.sourceCommit"
}

Input transformer – Input template

{
    "sourceVersion": <detail-sourceCommit>,
    "environmentVariablesOverride": [
        {
            "name": "DESTINATION_COMMIT_ID",
            "type": "PLAINTEXT",
            "value": <detail-destinationCommit>
        },
        {
            "name": "SOURCE_COMMIT_ID",
            "type": "PLAINTEXT",
            "value": <detail-sourceCommit>
        },
        {
            "name": "PULL_REQUEST_ID",
            "type": "PLAINTEXT",
            "value": <detail-pullRequestId>
        }
    ]
}

5. Create a feature branch, add a new file and raise a pull request

Create a feature branch following these steps. Push a new file called “index.js” to the root of the repository with the below content.

function greet(dayofweek) {
  if (dayofweek == "Saturday" || dayofweek == "Sunday") {
    console.log("Have a great weekend");
  } else {
    console.log("Have a great day at work");
  }
}

Now raise a pull request using the feature branch as source and main branch as destination following these steps.

6. Verify the pull request with the code review feedback in comment section

As soon as the pull request is created, the AWS CodeBuild project created in step 3 above will be triggered which will run the code quality check and post the results as a pull request comment. Navigate to the AWS CodeCommit repository pull request page in AWS Management Console and check under the Activity tab to confirm the automated code review result being displayed as the latest comment.

The pull request comment submitted by AWS CodeBuild highlights 6 errors in the JavaScript code. The errors on lines first and third are based on the jshint rule “eqeqeq”. It recommends to use strict equality operator (“===”) instead of the loose equality operator (“==”) to avoid type coercion. The errors on lines second, fourth and fifth are based on jshint rule “quotmark” which recommends to use single quotes with strings instead of double quotes for better readability. These jshint rules are defined in AWS CodeBuild project’s buildspec in step 3 above.

Figure 2: The image shows the AWS CodeCommit pull request's Activity tab with code review results automatically posted by the automated code reviewer

Figure 2. Pull Request comments updated with automated code review results.

Conclusion

In this blog post we’ve shown how using AWS CodeCommit and AWS CodeBuild services customers can automate their pull request review process by utilising Amazon EventBridge events and using their own choice of code quality tool. This simple solution also makes it easier for the human reviewers by providing them with automated code quality results as input and enabling them to focus their code review more on business logic code changes rather than static code quality issues.

About the authors

Blog post's primary author's image

Verinder Singh

Verinder Singh is an experienced Solution’s Architect based out of Sydney, Australia with 16+ years of experience in software development and architecture. He works primarily on building large scale open-source AWS solutions for common customer use cases and business problems. In his spare time, he enjoys vacationing and watching movies with his family.

Blog post's secondary author's image

Deenadayaalan Thirugnanasambandam

Deenadayaalan Thirugnanasambandam is a Principal Cloud Architect at AWS. He provides prescriptive architectural guidance and consulting that enable and accelerate customers’ adoption of AWS.

The collective thoughts of the interwebz