Thank you for coming to this session, you know, I wanted to talk to you a little bit about a project that we've undertook at UVA both to reduce our risk to user privacy, but also to enable librarians to do research on the data that we've coalesced. So today I'm going to be talking a little bit more about risk to user privacy, which we've heard a lot about at C&I today and yesterday. Also looking at trends for circulation data retention across peer institutions, talking more in depth about this project that we took on to lower our risk and enable library research, look at the aggregated data that we collected from across disparate library systems and enterprise systems and how that data is being used, and wind up with challenges that we overcame, challenges that we still face, and possible opportunities. So the first thing I wanted to talk about was academic freedom at risk. And I wanted to come at this from a couple of different directions starting off with a couple of examples at the University of Virginia. So in April 2010, the Virginia Attorney General, Kuchinelli, filed a subpoena seeking documentation of a climate scientist at UVA who was there in the late 1990s, early 2000s, and then went on to work at Penn State. And basically they launched an investigation saying that Michael Mann and some of his colleagues had actually made up fabricated research data to support climate change. Many organizations and individuals came out in support of academic freedom in this case and really saw it as a turning point. Over the next couple of months, it went to a Virginia circuit court who dismissed the investigation based on a lack of financial evidence. But soon thereafter in 2011, the American Tradition Institute, a free market think tank who also denied climate change, followed this dismissal with a FOIA request. It would take four years to come to the Supreme Court of Virginia, who then unanimously affirmed that the earlier circuit court decision was correct and ruled in the university's favor. But I can tell you, there was a lot of time on the part of our general counsel fighting to keep this information private. Also in 2015, we saw a lot of higher ed institutions come under attack from various nation states and other types of security breaches. In June that year, a federal agency notified UVA's CIO that in fact two nation state actors may have access to university systems. As you can imagine, this is something that no CIO wants to hear. And that summer turned into a massive undertaking, not only to find out the extent of the compromise, but also to plan out a remediation without alerting those actors. So this involves some 176 staff at the university, one government agencies, and two commercial companies who commenced to determine the extent of the damage or the compromise and also devised this plan for remediation. By August 2015, many of us who were unaware of what was going on found out at five o'clock on a Friday afternoon that the university was going dark. And for the next three days, the university undertook this massive undertaking to remediate the systems that were compromised and clear up the problem and bring the systems back online. And I'm happy to say that they did a fabulous job at getting us back up. UVA in the end learned that two faculty in particular who had visited China had been under surveillance for more than a year. In 2020, libraries published a lot of research on the growing problem of online surveillance and censorship. And by April 2021, Relics, a subsidiary to LexisNexis signed a contract, a multimillion dollar contract with the U.S. Immigration and Customs Enforcement Agency, ICE. The ICE contract revealed that LexisNexis databases would offer an oceanic computerized view of a person's existence and would provide the agency with the data it needs to locate people with little or no oversight. Both Relics and Thomas Reuters have built global surveillance systems that include online tracking. They have a massive growing aggregation of user data and evidence of a cell of services based on that tracking. And I'll wrap up this section by talking about the Patriot Act. In October 2001, the act was established and over the next more than a decade, it would continue to be reauthorized even with evidence of abuse. In March 2020, an effort to extend, once again, did not pass the House of Representatives and now the law is dead, but you might think, why do we care about this in this context? And it's because of Section 215, which stated that surveillance did not need to be reported. So even though we have all of these instances where we know that people have been under surveillance, it's what we don't know that's also deeply concerning. Because there's a lot of user data out there that's been gotten through this surveillance. So I'll bring it back to UVA and talk a little bit about the risk we were under at exposing private information of individuals. We had circulation data dating back from 2009 forward and this circulation data included the university ID, the computing ID, information about what people were researching, and that could be used to get other things like their first name, last name. And you might think, well, why didn't you clean that up? Well, every time we tried to clean it up, we would get a lot of pushback from individuals within the library that found this data vital to the research that they were doing in order to improve services, find lost items, have evidence to go back. We went to a very central budget or distributed budget model where all of the schools began being taxed for administrative services. So we had schools coming and saying, we don't use the library, so we don't want to pay that library tax. So we needed this data in order to show them that, yes, you do use the library and here's how. Also this data is interesting for informing collection building through usage trends, validating surveys, and in some cases staffing. And our primary risk was not for you because this is considered business data, but it was at risk for court orders and obviously security breaches. That security breach that happened at the university actually started in a department on an un-patched server that had access to the active directory centrally and from there those actors were able to hack into, I think, 20-some systems at the university. So one of the first things we wanted to do is think about what kind of retention schedule we wanted. And so we went out and talked to a lot of our peer institutions. And what we found is that people largely are not keeping circulation data at all or keeping it under 30 days or having an opt-in situation where the user has to choose. We do have a few people that we found that are keeping things for six months, a couple for a year, but there were only a few people who were keeping data unlimited like we were and all of us were striving to go to zero or go to some lesser extent. There was a lot of debate at our library. Some people wanted to keep it for a year. Some people didn't want to keep any at all. We finally got to a point where we could compromise at 90 days. And then in a year or two we're going to revisit that and see if we can go to zero. So our project goals were threefold. We wanted to reduce the risk to use a privacy. We wanted to augment the data that we had from these logs with data from other systems like Aeon which we now use for circulation of special collections. We use Archive Space which describes manuscripts and we have an in-house app that handles requests from faculty and students for digitization projects. So we wanted to coalesce this data from the different systems but we also needed data from enterprise systems. Every time we needed anything that had to do with roles of people who were using the library or information about schools and there was almost never any information about departments until recently in central systems, they would have to jump through a lot of hoops to get this data. So we wanted to explore what we could get from enterprise systems to enable better research and we wanted to provide an application that would allow them to search, discover and mine the data that we eventually archived. So one of the first things we needed to do was collaborate. I was at some earlier sessions where people were talking about the importance of working with an institution review board and in this case not only our senior leadership had to weigh in but we also worked with the institution research and assessment who had access to a data warehouse that could pinpoint the time and the date of a circulation record and tell us more about the individual and I'll later go into the data. The institution review board for social and behavioral sciences helped us look at the ethics of the data that we were proposing to collect and archive and we also worked with central ITS or technology services and the chief information security officer. We don't have a privacy officer. He sort of wears both hats to look at our overall system design look at the data that we were collecting look at every aspect and really be a consultant to our project to make sure that we were securing everything in the right way. And so all of this collaborative work ended up impacting our approach. So we revised our retention and archiving schedule. We worked on a de-identification but still retaining a unique it's almost like knowing that it was a unique individual without having their personal information. So we did that by using a salted hash where we had two pieces of information about a person that doesn't change very much. And then other special characters mixed in with it create a salted hash. This enabled the library to understand whether it was 50 people checking out 50 books or one person checking out 50 books and of course it had an impact on our security and access. So the data that we ended up collecting some of it was from the logs and some of it as I said was in this other systems. Time and date we were able to get school and department. This unique key is that salted hash I was talking about. The family group and family name has to do with identifying what role the person serves at the university. There's also roles. Of course borrower profile is part of our data. Faculty type whether they're degree seeking or not the degree level. This or library isn't populated with meaningful information right now but we think it will over time where a person identifies which library they prefer to work with. The station library item library location whether an item is part of the reserves. Skip that item data that's not meaningful. Primary subject and subject fields which was real holiday. Class schedule item type format publication date and language. So we wanted to give them the ability with this application to make available all the different possible values some of which are incorrect data but at least they would see it and be able to sift that filter that out. We also wanted them to be able to search by any combination of selected attributes and data so they could really narrow down the data set rather than having to sift through a large data set for something unique that they're looking for. We wanted the ability to be able to browse through pages of results to identify that they were actually getting the data that they needed. Often these terms and the values that turn up mean something different from what they thought it meant. So a lot of times they'd have to go back and modify their search to get the right data set but once they have the data set that they need then they have the ability to export the data for further processing. After looking at all the different ways that people needed to conduct the research we decided that it would make the application too complicated to be able to take care of all that and there were other technologies out there that could better do the job. So some of the technical decisions we made were to automate everything so that we could meet the retention schedule. We wanted to base it in cloud infrastructure because all of our applications, most of them are already in the cloud and the ones that aren't are quickly moving in that direction. We decided to use a solar index for speed and flexibility and we wanted to export in CSV format for post-processing and one of the important factors was the ability to archive all of these source files that we were getting from different systems because once things came back to us from our ID identified we had no way to go back and recreate that data. So we really needed to archive those source files for disaster recovery. I wish that I had our library assessment library in here. She wouldn't get on a plane and I appreciate that but she's going to do a much better job at describing how she went about forming a sandbox and the different things but I'll do my best. So one of the things that Annette Stahlnacher appreciated was access to the living data and the aggregation across systems because she was one of the people who had to go through these hoops every time, you know, the administration wanted to prove one thing or another. She would have to work with all these different departments and coalesce all this data from other systems and of course it never came in in a timely fashion. So she really appreciated being able to aggregate all this data from across systems and have it at her fingertips. She used a couple of examples to conduct longitudinal analysis which she does on a regular basis and she's also the person who works with other people to put together our surveys and she's used to looking at results that come back and how do you know, you know, is the information that you're getting actually valid or not. So she sees the data as being useful for validating surveys or doing what she calls myth-busting. So one of the first use cases that she used as our School of Commerce, McIntyre School, was one of those schools that would come back and say we don't use the library so we don't want to pay you the tax. Well, what we found out by looking at the data is actually that's a myth. Circulation was consistent. She actually pulled data from 2009 all the way up through 2020 to look at, you know, has it changed over time? Are they right that people don't use the library or are they consistently? And they are consistently using it mostly for books and DVDs. Also she learned that the most heavily used library is Clemens, which now has more collections but traditionally that was thought of as the undergraduate library. And she found out that the most common borrower profile were undergrads. The next question she asked is what classifications at a high level are faculty using? So by department she wanted to know which faculty used the library most often and not surprisingly it's English and history and they already had a pretty good idea that that was the case. And they wanted to know the library most used by faculty and they also weren't surprised to learn that the main library was the library that they used the most but we also knew that everybody, the faculty love our Leo service which is our library delivery service for faculty. She also wanted to verify that the P's as expected had the highest circulation and it did English literature was the highest subclassification of the P's. So she didn't really turn up anything that was earth shattering there. Next, Beth Blanton Kent or Beth Blanton I think she now goes by informing library collections. She was the person who for over a decade had been begging for this data to be pulled and data from central systems because she is constantly being pressured to, you know, build collections in the direction of, you know, a changing landscape among curricula, you know, greater degree of interdisciplinary studies with diversity, equity and inclusion. She's constantly asked, how are you serving these populations? So she wanted to know who really uses what, who do I talk to? You know, what are the usage patterns say versus the anecdotal feedback that she was getting? Like Annette she wanted to do immediate long-term analysis of the collection use and have data at her fingertips to be able to do better management, better maintenance decisions. Another thing that she really desired was can we correlate user success to collection use? And this is one of the big factors I think where we come to budding heads over collecting data is, you know, we want to know if the library actually contributes to user success but at the same time we have this commitment to protect their personal information. So we still do not have a way to correlate this but we're trying to find other avenues because as we all know when you give up information to another entity it's very hard to get it back. One of the cases that she looked at does interdisciplinary or shifting research impact collection usage and she wanted to look at archaeology which she thought what she would find is the art department that has the archaeology studies or anthropology. That's what she expected to find. What she learned is that history usage left those other departments in the dust and she learned that student usage was double that of faculty which was a real surprise and that most materials were circulated between 1 and 2 p.m. She still doesn't know the answers to why this is so but now she's wildly interested in talking to people. Another case that she looked at because they had just overhauled their Arabic collection plans was who uses the Arabic collection and surprisingly she learned that the school of continuing and professional studies also heavily used the collection and learned that overall use was evenly split amongst faculty, graduate students and undergraduates. She had never thought about contacting that department at all about the usage of collections and certainly not the Arabic collection but now she's more informed about which departments to talk to about the uses of different collections. And then I had Cecilia Parks on the project who represented teaching and learning but also all of the people that are working with faculty and departments and students and the things that Cecilia was interested in for her area was understanding use patterns amongst departments, subject areas and all the different user groups that they work with. Again, verifying anecdotal evidence, you know she keeps hearing that undergraduates say they want fun fiction and she was curious what does that mean? Like what are they checking out? What do they think is fun? Identifying collections and areas for outreach and development and also identifying areas for instruction which is primarily where she's focused you know maybe building tutorials for finding books in a specific location or a call number range. And she was the one who originally came to me and said somebody told me that you were the person who has talked about basically coalescing this data in the past and I'm working with diversity, equity and inclusion efforts and we're really interested in knowing more about that and knowing how that compares to how we're building collections and how people are using the library. Unfortunately, even though that's what started the project discussion off, that was something that we found we were not going to be able to do and primarily that was because the enterprise systems did not even support the concept of gender and race until the last few years and even when they did sometimes people were only given a binary option and so the data in the systems is not only incomplete but it's factually incorrect which I wish was the only place we found incorrect information but I guarantee you it was not. We also see a potential use on the front lines primarily if you're looking at location usage trends for instance like a department primarily using Clemens. The item location versus the circulation location like maybe if you find out that the majority of this collection is being requested in this building maybe you want to move those items over there so that you can make things more efficient. Also circulation trends by date and time you know when are your peaks how many circulations are you doing at this service point versus that service point should you have more students because we employ a lot of students on our front line services should we have more of those working in one building versus another. So some of the challenges that we encountered I've already talked about the DEI data system and data migrations across the university whether it was an enterprise system we've changed I've been there a long time but we've changed our HR systems at least three times the library just migrated data from ILS to ILS to ILS and didn't clean things up for good reasons but there's a lot of stuff out there that we've been trying to clean programmatically but in some cases people have had to go in and do things by hand so central systems aren't the only ones that have interesting data in fields we wouldn't expect but we're appreciative of the things that we do have. Also there's a problem we have to weed the collections and that left a gap so if we were looking at a circulation log we only had part of the data so we would want to look up in the ILS and get current information about that data like you know what are the subject fields what are the subfields what are all these other location information about that particular item obviously if you've weeded the collection and you no longer have that record in the ILS you're not going to be able to do that but we still kept as much data as we could about that item and because librarians are able to see the data and filter on the data it's much more visible to them now than it was in the past the other big gap the largest gap is that we have an increase of digital content and especially with the pandemic and on non-learning we're only going in that direction further and so far the University of Virginia Library has been a place that did not want to make people authenticate for everything that they access so I know that I've been asked many times in the past why can't you tell us how often how much people use our spaces it's like well if you want to put gates at the door and have people authenticate and swap a card every time they come in we can tell that but the best we've been able to do with that sort of thing is put in sensors that don't do a great job at telling you how people use the space but it's the best we've been able to do without authentication we also don't require authentication for access to digital content and it's a real problem because you know this is going to make the data less and less complete as time goes on so we're trying to figure out what to do I was interested in the talk yesterday that Sarah and Lisa gave talking about these new technologies in ways that we might be able to leverage them and I'm wondering if we could partner up with the publishers to get some of this data back about this authentication delegation that they're going to do with institutions that have SAML in place you know UVAs had SAML in place since the 90s so we should be an institution that should be able to leverage something out of that and also be able to tailor how much information we turn it over to publishers so I wanted to talk about opportunities I'm curious as to how many of you have undertaken similar projects like do you collect this kind of data do you have these same kinds of research questions have you been able to I know that now that librarians have seen this data they want more they're thinking of other data that they'd like to collect and add also to this collection and do other kinds of evidence-based research and be able to make more data-driven decisions about improving services so I'm just wondering you know how many of you've done it and also you know what could we tell about the change in research libraries if we were to aggregate this data you know is there a possibility if we de-identified data at different institutions and we had an aggregation could it better inform us about trends and changes of discipline changes in curricula changes in student populations and the way they use our collections so I'm curious to hear and also answer any questions I want to quickly go through some acknowledgements this was our team I'm forever thankful for people working so hard for what took us about a year to get this off the ground I also read a lot of different research particularly in talking about the attack on academic freedom and these were some of my sources and of course I'm glad to answer any questions about the project but I'm wondering if some of you would be willing to share with me similar projects that you have or if you have questions at this point can I get a thank you can I get a show of hands how many of you have done some kind of data aggregation like this fair number Jamie hi Robin Jamie Wittenberg University of Colorado Boulder library is I'm curious if you could talk a little bit about your model at UVA for data governance and stewardship around these kinds of data at the library level and at the campus or university level and how those how those models either enabled or obstructed your ability to do this work so we have recently just in the past four years the CIO led an effort to come up with a data governance group and I think it includes people like from IRA and IRB the CIO's office in talking about these matters but projects like mine didn't really go through that they went in into the different components in that group instead so to check security and check ethics but I think as it matures over time maybe we'll get a chief privacy officer in addition to the security officer and that things will travel in that direction more often so I'd say it's pretty new and it's not really matured thank you Lisa hi Robin Lisa Henshleff University of Illinois at Urbana Champaign I really think this is really interesting and so thoughtful the way you've really tried to grapple with some really challenging issues here of you know if you're being challenged by hey our students don't use the library it's not enough to just say a lot of students use the library you need to be able to respond to that challenge what I'm actually interested to ask you about is could you say a little bit more about the intersection with IRB and particularly it feels like you're saying that at least some of this is falling outside this purview of IRB but does any fall inside and under what circumstances it was okay it was really interesting I expected them to weigh in more heavily and what they did they were glad to help but what they initially told me was we usually just work on grant projects but we're happy to talk to you and so you know we went through and I explained the whole project to them and they did actually help us think about the ethics and they said that the way we de-identifying things they felt like even in the event that we went through a security breach there wouldn't be enough data in there to actually damage the reputation of anyone it wasn't powerful enough to actually impact or damage and that was their main consideration but I expected it to be a lot more involved than that so what I'm trying to understand so do you actually have an IRB approval for this or they consulted on the design they actually approved okay so you are then able to publish anything you want out of this data or would a publication trigger the need for an additional look at the particular research project no I mean we're able to present on it they didn't they didn't restrict any publication because it's so general and you can't identify the person and we don't have any PI in it so okay I appreciate hearing about this so for the last three years I've been running a project in Illinois called Carly Counts which has been teaching librarians across our state about how to gather data analyze it and the like and all I can say is that this past year where we had people doing projects in teams where we would have projects with like four different institutions so that actually meant four IRBs weighing in the inconsistency about how libraries are treated by IRBs is a major challenge to the slide four slides ago that talked about doing compare contrast aggregate including I mean it's I it's a whole talk I won't give it in a question comment here but this is really interesting I mean we have one project we have two projects where essentially one person had to essentially withdraw from the project so that the project could go forward so even though the University of Illinois at Urbana-Champaign with a medical school our IRB approved it etc a particular community college would not approve the same project and so I don't think you know it's it's just I think so this is one of the things I want to kind of raise in the context of what I think we are needing to do which is to ask ourselves how are we doing this across the field is kind of trying to surface the differential treatment of library data within the IRB uh rubric some of the IRBs also wouldn't do IRB because they said it's management data not research data but that's fine unless you're on a project with somebody at the University of Illinois and our IRB says it's research data so now we have two rulings one of which is it's outside of IRB one side it's inside IRB so sharing some of those experiences but I really wanted to understand a little bit more of what your IRB did which is a whole new version I appreciate that because I think IRB took more of the first stance which is we only work on grant funded projects for researchers why are you coming to us so yeah it's interesting hey I'm Yasmine Shortish I'm at James Madison University I have a question um in particular about that this idea of how do we know if art students are using the library or whatever did you all have any discussions about how to answer those kinds of questions without collecting data well it was I would say it wasn't totally impossible to find out about students as a large group so because of the borrower profiles right so we get information from student systems although I will say staff override that because they have the ability to in the ILS so for instance I'm treated as a faculty member and I've been staff forever so I have a different borrower profile but it doesn't give you any kind of information about the department or the school and when you ask central systems about that you would get partial answers and people really reluctant to give you the data and even now talk on the enterprise systems if we weren't working with the people that had the data warehouse it would have been very difficult and for a long time the university didn't even keep information by department which has also come up I just have a follow-up I guess I'm I'm wondering uh I don't have high confidence in like down the road our abilities as libraries to keep the data in our circulation systems and in enterprise systems like to have agency over it because of the vendor tentacles and so I'm I'm just wondering if we go to data because it's there and we think it can give us answers expediently and efficiently but are there other kinds of methodologies that we should be investigating to to actually move away from an over reliance on data and this data driven ethos right and that there may be other effective ways that get to other things that are harder to count about relationship building and growth over time surveys do you guys do surveys yeah we've always relied on surveys to give us a lot of that information as well but of course that's you only get a certain amount of response and I've heard a friend of mine was sharing this last couple of days about a massive effort to survey students and they don't yet have the results of the information that they got but they got really good response you know our response rate varies over the years and so you wonder you know how valid is it to extrapolate from the population that is actually presented with the survey in the first place and then the number of people that answer it which can sometimes be pretty low hi Robin I think it's the Virginia contingent here so Irene Harold VCU and so I'm wondering have you approached Viva as to look for partners or just I meet regularly with John Unsworth and Tyler Walter of Virginia Tech and and your Dean so you know maybe there is a possibility of us all collaborating love that idea you can tell him I Irene sent you okay if there's nothing else I think you can have an extra 15 minutes thank you


A study by Boston Consulting Group, a global management consultant firm, has shown that Nigeria and fought for other countries around the world as severely exposed to the Ukraine war-induced food crisis. B.C.G. in a report titled, the war in Ukraine and the rush to feed the world said it explored in detail the multiple direct and indirect impact of the turmoil in Ukraine on global food systems. The report, co-authored with Food Systems for the future, also provided 13 near and medium-term solutions to help respond to the crisis and improve the resilience of global food systems. It said the affected countries which were concentrated in Africa, South Asia, and Latin America were hotspots around the world as they endured some of the worst effects of the crisis. NEWS OPDATES


Hello, welcome to my session about the year 2038 and what it means for U-TEMP, WTEMP on 64-bit systems, especially on Windows as you can see. My name is Thorsten Kuckuck, I'm the scientist engineer at JUSA, I'm leading the Q&A team. I'm now with the company Science for over 24 years and looking back at our over 25 years as a software developer in various areas starting from Q&A to U-TEMP and similarly allowing user-friendly stuff. So, in the year 2038 on Unix the 32-bit Tine-T counter with an overflow. If you never heard about this, then there is a really good Wikipedia article about this, but in short the Tine-T is a Unix counter starting at the January 4th 1970 and increased with every second since it's a 32-bit signed variable on most operating 32-bit operating systems with an overflow. And there is no universal solution in the C-language, any change to the definition of the time T-data type would reside in IPI breakage and code compatibility problems. Everybody who is currently working on changing a 32-bit U-TEMP system to use a 64-bit Tine-T knows what I'm speaking here. It's although not possible really to frame the signed in-tata to an unsigned one because then you will use the possibility to present a date before in the 1970s and the fault is similar to increasing it because you also have to look at the source code using this variable if it is okay how to use it. Increasing the size of time T to 64-bit, the existing system breaks the layout of structures and binary interfaces of functions. Again, the people currently working on 32-bit distributions switching to 64-bit time T now what I'm speaking about. So now 32,038 is far, far away and many people say that they will only support 64-bit architectures until then which have already 64-bit time T today, so why should they care? The answer is very simple, if you look at the header files of GDPC, there is this define for compatibility between a 32-bit and 64-bit user land at the same corner in the same system and this defines the seconds as a 32-bit int and not 64-bit or the system default. Which means even x8664 with GDPC on Linux is affected by this and U-Temp will stop working in 2038. If you look at the affected API by U-Temp or the double temp you will find a long list of functions and if we change the struct we have an IPI break it for all of them. Except the one where you set the part to the file that stay compatible. So two functions out of the list will stay compatible, the rest has an ABI issue. And the affected files are run U-Temp, VALOG, W-Temp, VALOG, LastLog, VALOG, B-Temp and maybe more who are using this struct. Now of course people think already signed some years about how to solve it. The one idea of course is to use 64-bit time t everywhere. So adjust the struct in VDPC to use 64-bit time t in the struct U-Temp always on 32-bit and 64-bit systems. But this is a big headache and it's in the same scope as the 32-bit link distributions going through who changed the time t bit. It's a massive API break it, since you cannot use simple versioning or for structs or variables like the problem is solved for the rest of the 32-bit time t transformation in VDPC. And the worst thing is there is now API for LastLog for example. You have a header file which defines the struct, no functions. So you would need to touch every single application to do it correct and work with it. Some people tried some proof of concept implementations how to solve it on VDPC level. But the developers decided that they don't want to change the current U-Temp interface anymore but they want to declare it as legacy and drop it in the feature. So that makes it pretty hard to come up with a solution on a low level. Additionally the current U-Temp implementation or design, it's a design problem more or less, has a security problem. You can make a denial of service attack so that root cannot lock in anymore and you cannot solve it on VDPC level but you need a demon for it. There is a bug report in the VDPC tracker for this one who want to know more details about this. Another idea is there is free space in the U-Temp struct in VDPC. The VDPC developer reserved it for future enhancements. Now one idea is can we not use that tool for and store the bigger value there. The first problem is VDPC developers don't want to touch the U-Temp code anymore but drop it. So at this moment already it's clear that it will not happen but there are also some big technical things, logical. And one of these problems is we have an application compiled with the old VDPC with the old struct U-Temp. It writes something to U-Temp then we have an application which is using the new struct already. It reads the old entry, it does not find its data. So it will not really solve the problem but will create a huge amount of problems because you have to change all applications at one time. You have to migrate all existing files and so on. So let's start with the easy files interfaces we have last log. Last log stores the information when a user did log in the last time. It's storing the username, the port from our TTY and the time. And it will be found at the next log in time as last log information. So as I said there is no API for this. There is only a struct and header file which means every application has to implement it at their own. It makes it pretty hard to convert it to something new because you have to touch every application. Additional, we have the problem that only log-in in SSH have real support for last log. Else, there is a PEM last log module with some distributors and some applications uses and configures other not. So on my desktop at home if I type last it claims I did log in the last time last year November. Even if I did log in at that day because somebody did not configure this display manufacturer to use the last log PEM module. So it's also not trustworthy so we need something completely new. Besides that the current last log format has a problem. It's using sparse files and with big UIDs you get really large files. And at the moment where the file system or tools don't support files with big holes and don't support them then you have a problem there. So we did implement last log 2. It's replacing the last log implementation by using an SQLite database to store the data. It's implemented as PEM module so you can configure it for every service where you want that it stores. You have the last log information and that it falls at the next log in time. You have it in one place code so it's easy to update, to adjust and to make sure that it is stored in a safe way, the cool way and always the same way. We have a last log compatible last log 2 command where we created a compact sibling tool. It can import the old last log file and the future is that the Utilinux maintainers want to merge last log 2 into Utilinux. So as base and drop their own last log implementation. Then open through the tumbleweed, micro s and I'll reuse it already signed several months. I got doing all the time only one bug report because somebody was missing one last log. Now that was the VTEMP. For this we didn't got any bug reports, nobody noticed it just working. That was a good thing. Now WTEMP, this file records all log ins, log outs, boots and shutdowns of a system in a historical way. They are beside this for entries, some other types which can be stored in the pre-system D times or maybe still today with some for init daemons. The run level is stored there but the system D it does not exist. That's the concept. Then it stores the new time field. When I did the analysis during the year who is using WTEMP and why I found one application which is reading this field but I didn't find any application writing that. So at just time who is reading this field will never find this in a VTEMP file in my opinion. And then there is all time where I only found several comments what is it who is using that but I couldn't find any usage or definition of it. And the file is written more or less by all applications performing a log in. So additional problem with the VTEMP format as we have today is that there is no common rule what I should write into this file and at which time. So if you take VTEMP as example the GNOME display manager it creates always two WTEMP entries for every log in and log out which is not a problem per se but confusing. Then you have like DEMP which is always using DevConsole as TTY. If you look ever at the last source code then you will see that last is using the log in name and the TTY to find the matching log out and log in entries. If you have now always the same TTY and if users log in on several X displays or something similar then with this last is no longer able to match log in and log out records and what last is displaying is wrong. It looks like that nobody really cares I didn't find a bug report but I could reproduce it that last is creating wrong output in this cases. And then some few terminal emulators write WTEMP entries others do not so you have inconsistent data. Who is using that file? Last is the most prominent and often used application to read this file and then there is LS log ins who is reading it and some few others but it's really rarely seldom to access this file. The solution here is also to use an SQLite database to store the data one entry for log in and log out. Since we have a database we have a unique identifier uniquely for this entry and can update the same entry. And we also wrote a PEM module to update and to have all code on one place like this last log and we have a last compatible command which forces the information. And this is where I got in all the months we are using it now one bug report because once option of last was not implemented but will follow the next days or weeks when I have time. So we integrated this already in OpenSUSE as the PEM module is installed by default and configured by default. The applications and their configuration are adjusted we have compact symbolings and until now as I said there was one last option which some user found out is missing else it looks like nobody noticed that we switched from VTEMP to VTEMPDB already on OpenSUSE. Now the next step will be to disable VTEMP support in all applications so that they don't write the file anymore. And now the most interesting one is the UTEMP file. The UTEMP file allows one to discover information about who is currently using the system. Again there are now common rules what you should write into an UTEMP file and there is quite a lot of discussions between different developers of different tools which ends in that for example XTerm and Consola write UTEMP entries. GNOME terminal does not write this entries. And if you call Uptime you will see that Uptime reports the users locked in on the system. But this is pretty meaningless because it doesn't tell you if you have 10 different users on the system or if there are only one user who is running nine XTerms and maybe 200 GNOME terminals. So it doesn't tell you anything this value. Also the API has no error reporting so if the UTEMP functions don't return a new entry then it does not mean there is none it only means for you nothing you don't know. And the design issues including the denial of service attack also exists for this. If you lock the UTEMP file you cannot lock in any more as root and you can lock it as normal user. Other problems is that user names and devices are limited to 32 characters. If you look at the header file for the kernel or glibc normally you have much bigger limits or no limit at all. Which means if you store a user name with more than for example 33 characters it will be truncated same for device names. And which is also a little bit a security risk is that the strings are not null terminated if they fit exactly in the variable in the length of the variable. So if you read such a field you have to look for the zero operator or that you read 32 characters. And I did read a lot of code to understand what applications do with the UTEMP file and the data it contains. And a huge amount of them have in the one or other place a problem and will read behind the string. Because they did one of the effects in some cases wrong. So when I brought up this problem the first time there was also a nice in this regard comment from Luca one of the system media that pass on Linux weekly news. And and thought we should stop limitating Linux. Because we use we should not look at the least common dominator Unix of 30 years ago nobody remembers anymore. Looking at the commercial Unix 30 years ago which has this limit happens before to remove them because Linux in reality don't have this limit happens and be put as I said not limit by us by the past. To now find a solution how to replace UTEMP at first I analyzed who uses this file and information. And one is the inner demon for process management. Not with system D so we don't need that. Then we have a huge amount of applications writing UTEMP entries for others. Log in SSHD, XDM, GDM, SCDM and all you can continue this list. They all only write the entry they never read it again. And then you have a few applications which read this file and use this data. It's not most like W who uptime wall write. QEMO, Samba are also some tools which read the information and display them. So it's a limited number of applications. And then I grouped them in common usages. Most of the application only use the UTEMP file to count the number of logged in users. So every graphical terminal is a new user in XTEMP. But if the graphical interface is using for example GNOME terminal which is not writing this file then it's not a new user. It's already as I said they are confusing. It makes these numbers not really reliable. Then you have tools for information about logged in users. It's who, it's W or the Samba and QEMO are using it for this case. And then you have the wall messages sent to our logged in users. For example if you shut down the system. And here it's local logged in on console users if you log in, remote logged in users SSH. And then you have the desktop users. So our GNOME user in the team tested it. He was using the GNOME terminal. He did not got a wall message. The KDE user got it. Even if you had no terminals because KDE creates a dummy UTEMP entry to get these messages. So in my opinion this is something the desktop developers need to solve in a better way. And not working with fake log ins or expect that every desktop user has an XTEM or a console open which is creating an UTEMP entry. So the solution for most of the problems is to create a new library with a demon. Such implementation exists already like UTEMPS. But this only solves the 32 bit time t problem and is it cruelty problems. It does not solve the API design problems. It does not solve which is now error handling the access of the struct. And you need to review all applications independent if it is a 32 bit or 64 bit applications that they handle the 34 bit time t correct. And it is another demon running on the system. But we have already demons on running on the system. Why should we create another one? And if we have to review and audit all code using the UTEMP struct and functions. Why not create something completely new without all the problems? Because writing secure new in a library or whatever is as expensive as reviewing and fixing all the code and searching outside there. And we have a demon which is already running on system D systems. And which is collecting all the data already sent several years and that is system D log in D. It is used on all system D based Linux systems for the non-system D one. There is for example E log in D which provides the same functionality. It is made for and this should be hopefully secure. It has also said it has all the data already collected via the PEM system D PEM module. And there are several interfaces to it. You have log in CTL, you have adipose interface and the system D. And with the system D signs the last release or 254. It also provides all functions you need to replace UTEMP. And this is looking then in this way the mapping. So for the UT type field only user process is supported so we don't need that. UT PID, we have the SD7 get leader function which providing exactly this PID. For the TTY we have the SD7 get TTY function. The TID is the session ID. The UT user is the SD7 get user name function provides it. The host is the SD7 get remote host function. UT exit and UT7 we don't have replacements in the system D. But I also haven't found any application using this two variables from this tract. And the log in time we get with SD7 get start time. There is a little key but in this because you can already start a system D7 before you log in. So this time is in this case not really correct but it's the best we have in this case because it's really a question if I start a 7 which time counts when I start the 7 or when the data is the user access attached to the session. So it's also the definition. And IP variable is then the UT host it's identical in this case. If you know the UTAMP ABA function it's in the end you call setUtent. You have a while loop about every entry you pass a struct you call endUtent and you have all information about the log in users. So if you use the system D the SD get session function is identical to the setUtent function more or less you initialize the data structures and you get a list of active sessions then you iterate over the sessions. You can fetch with the functions I mentioned on the previous slide all information you need and you can get much much more information which UTAMP does not provide. So the NULIP developers already use this and query also additional information from log in D and somehow encode it in their tools. For example if you use who from core hotels with this you will see additional output which UTAMP normally does not provide and in the end you free what you got you are done. If you look now at the common usages from the beginning for what UTAMP is used counting the number is really simple you just call SD get sessions with a NULP parameter and you get the number of logged in users. And since we have one instance log in D who controls what is a new session and what not this number is now really reliable. You exactly know how many different users are logged in on your system Informations about logged in users are found in who and we with this Compatible versions of W and who are and similar tools already exist and most all are already released. Other like Zumba and QEMU are currently work in progress. And for wall messages work for local and remote console users because log in D now who logged in it does not work currently desktop implementations. As I said this is something the desktop people need to solve. The display made for our Greta has a TTY it gets the messages they only need a find to provide it to the logged in users who are not using a terminal but maybe only a web browser or something similar. An analysis of the packages on the open to the tumbleweed installation brought up a lot of packages which are affected and need to be changed. Everything which is dark green on this list is already able to or is already using log in D instead of U-temp and there are already released verphins which means on open to the tumbleweed for example a micro s you just need to use them and they will use log in D and no longer U-temp in the background. So either the projects brought their own patches on support for it like the GNU-Lib developers that's why quality e-max and other GNU applications will support it latest if they update to the current GNU-Lib version or they accepted our patches like PEM, PROC-PS, system D, monitoring plug ins. Fedor also created their own application support. The light green one is this application which use U-temp but which we don't need to touch because it's enough to modify the PEM configuration and add PEM system D to it. The blue ones are the one we don't need anymore. We don't need a helper application who writes to U-temp because that's done via the PEM system D module. The orange applications are the ones where we have patches and which are already part of open to the tumbleweed but which are not yet upstream. Open SSH for example does not react at all to our mails and pull requests. Others, I didn't have the time yet to speak with U-temp maintainers and then of course we also have some maintainers who say 2038, it's far, far away. I don't care, go away. And the red ones are the ones where I'm asking if we really need it anymore. Act for example was the last patch six years ago but they are convertable if somebody has time and so then we have some applications writing U-temp entries like screen script, what should happen with them. So in my console opinion and that is what most people also agreed with me in the discussions in the last month is that Xterm and console and similar tools would not write U-temp entries like Nome Terminal. They would not fake entries so that they get the whole message but they need to be solved correctly in the desktops. And then we have cases like screen-wise U-temp entries but it's not a log in session, it's not a real session. Tmux does not write U-temp entries on all Linux distributions so it's a big mess there and Zudo is the same, Zudo writes something U-temp entries so does never. Discoffs with the upstream system D maintainer thought that they don't think that Zudo could create a new session and that's why they block it in their code. I can partly understand it and agree to it but yeah, that's something which is currently interesting. So what is the status of this in regard to open to the Tumbleweed and open to the Micro-S. So we have system D with 254 signs last week and with this we also release co-authors to Linux, proc.ps and many packages more who are now using log in D. So since one week open to the Tumbleweed and Micro-S are using log in D and no longer on U-temp for the most applications and I haven't seen any comment I announced on the Tumbleweed mailing list, no reaction, no bug reports so it seems like nobody is really noticing it that the informations are now coming from another data source because the output is the same. So what's missing is system D is using internal still U-temp for the warm-up messages. I fixed that two weeks ago so with system D 255 we can really build a system D without U-temp support at all. Coomu and Zumba they need to be converted. Zumba I have patches, I tested them, they are working, I only need to contact upstream. Coomu would be even easier than Zumba and then I hope that we in some months can disable writing U-temp entries at all and have a system which is in regard to U-temp, W-temp and last log here 2038 clean. There are some references. I wrote a block with a lot of background information and feedback from others. There is a Git repository for me where I collect some files with lists of all projects and what is done and what is still open to need to do, a document which describes how to convert from U-temp to log in D. I have also directory with patches for packages which are still work in progress or where I didn't have the time to submit them upstream and there is a repository with binary RPMs for Tumbleweed with all the RPMs with the patches but it means everything is in Tumbleweed that is not needed anymore. Are there no questions? I don't see anything in the publicum because it is so dark. Are there any questions about this? Any concerns? Other ideas? Oh, there is one question. I don't know if I have a microphone. I think I come here and then I repeat it. It is my better. That is the question was if we already tied it with a computer running in the year 2040 or something similar. Currently we have test cases which emulates this by calling all this code with effect time. We have not installed a real system because this is only about U-temp, V-temp and last log and it is not about all the other stuff which is still using 32-bit time T which means currently, no, until one or two months ago even our installer was not able to install on such a system. We have not been able to install on such a system. These are other teams that are working on it. I know Debian is working on replacing or switching from a 32-bit time T to a 64-bit time T on their 32-bit distribution. They are also working in progress and that is why I got so much help from the new developers because the Debian people complained to the new developers and that is why I got so much help from Debian. So it is currently everybody is doing single steps but we don't have a full thing which could work together. But this already solves some problems like security issues, no error reporting and similar things. More questions. Yes. That is a single missing feature I mentioned which is working in progress. Reinhardt Max, I think you know him, promised me to implement it but he didn't find the time for it yet. I think I have to look at it myself if I am back from all the conferences now. But it is on the to-do list. The question was the last comment has an argument that you could list the users, you could specify a user name and then you could get all the information that you need to list the users. This is what I mentioned is missing but we will come. Yes. Because I don't have 15 more years, I have a few months for this. The normal desktop lifetime is about four years so they have plenty of time to solve it. But if you look at the enterprise server market or embedded market or edge market, then you can create now the distributions which have a longer lifetime and will still be available and running in 2038 and later. And this is a change you don't want to do with a maintenance update, especially as we have these users, I think the others have the same customers who want a distribution where we guarantee that without update and modification it still runs after 2038. So it means, yes, in some use cases there is plenty of time, in other use cases we have no time anymore. That's why I started with it at all. Because we have the time preffer, we see them. So more questions. Yes. I didn't understand regarding what? The question was about BI systems and having applications, 64-bit and 32-bit applications running on the same system, how it will work or not for 32-bit applications. The answer is binaries as of today who are 64-bit, x8664 or 32-bit, x8664 will stop working 2038. There is no way to get them running there. So this, oh, I see it's, okay, it's going to jump in. So you have to adjust this application and if you use log in D, all what I told about 64-bit is also true and will work with 32-bit. All the interfaces of lib system, D, of last log 2, all of them are using int64. So the different, and not in seconds, but I think it's micro, whatever system D is using there, I don't remember exactly, I have to look up. So we are self in this regard with this on both architectures and of course, since they're all used in an int64 type, they're also compatible to each other. Yes? So the question was, if we make, disable the code in Vlipsy, will check tools, create a warning, will that fail or not? So today, Muslipsy, for example, has the function and is returning in all this, no data. With Vlipsy developers, plans the same. How this affects static code analyzers? If they can detect it, I don't know. I'm not in that business. I spoke with our compiler people and they said, there are some ways to detect it, but there are so many options with casting and accessing the virus and so on. They say, we tried it and we got more false positives than real positives. So yes, I think it is a nice search topic to write a static code analyzer who is going over the source code and tells you where you have a problem with 32-bit time T in the year 2038. I don't know if somebody is working already on that. I haven't got any feedback about this. More questions. Okay. Then I want to thank you that at least a few people tried to fill up this big room and thank you for listening.