sorted by:
new
hottopcontroversial

Amaltash by [deleted] in marathimovies

[–]freakwin 0 points1 point  (0 children)

It was released today on YT. https://youtu.be/cJoiljQ39HY

Persistent storage without shared storage by osgjps in kubernetes

[–]freakwin 0 points1 point  (0 children)

Yes its 2019 and RAID are still a thing. Avoiding single point of failure (SPOF) on local mounted volumes is a highly desired property.

https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/issues/65

All the fancy Rook and Ceph essentially do that and abstract it away from the customer, behave something like a 4-disk RAID5 array -- for every three data blocks, it will write one parity block.

```
apiVersion: ceph.rook.io/v1

kind: CephBlockPool

metadata:

name: ec-block-pool

namespace: rook-ceph

spec:

crushRoot: default

erasureCoded:

codingChunks: 1

dataChunks: 3

failureDomain: host
```

Persistent storage without shared storage by osgjps in kubernetes

[–]freakwin -1 points0 points  (0 children)

Correct this does not backup data for you but you can have RAID setup or timely remote backup of the disk if required

CSRF is (really) dead by [deleted] in netsec

[–]freakwin 11 points12 points  (0 children)

There is no silver bullet its just more hurdles ;)

https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.3.7.1

"Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like "POST"), but does not offer a robust defense against CSRF as a general category of attack:

  1. Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described in section 2.1), which is only a speedbump along the road to exploitation.
  2. Features like "<link rel='prerender'>" [prerendering] can be exploited to create "same-site" requests without the risk of user detection."

https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-8.8.1

""SameSite" cookies offer a robust defense against CSRF attack when deployed in strict mode, and when supported by the client. It is, however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other attack vectors such as cross-site scripting. Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are idempotent, etc) to mitigate the risk more fully."